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Introduction 


For  over  six  years  scientists  in  the  Satellite  Meteorology  Branch  of  the  Atmospheric 
Sciences  Division  of  the  Geophysics  Directorate  of  the  Phillips  Laboratory  have  been 
utilizing  a  computer  system  known  as  AIMS  in  support  of  their  research.  During  that  time 
both  branch  and  divisional  requirements  have  increased  significantly  for  computing  to 
support  research  in  the  atmospheric  sciences,  resulting  in  concomitant  growth  in  AIMS 
hardware  and  software  resources  and  the  number  of  users  supported.  Aggregate  CPU 
processing  capability  has  risen  by  1700%  over  the  past  six  years  and  fixed-disk  mass 
storage  has  increased  by  400%.  A  relatively  new  removable  mass  storage  media  based  on 
magneto-optical  technology  is  now  used  extensively  in  cloud  analysis  studies  to  store  high- 
volume  polar-orbiting  and  geostationary  satellite  data  and  ancillary  datasets  such  as  fine 
resolution  (6  km)  topographic  data.  In  total,  the  use  of  this  media  alone  approaches  20 
gigabytes.  In  parallel  with  the  physical  growth  of  AIMS  the  number  of  user  accounts  have 
tripled  since  1986.  Today,  AIMS  supports  50  user  accounts  cf  which  approximately  half 
use  the  system  on  a  regular  basis. 

Part  of  the  system  growth  has  been  attributable  to  the  expanding  need  to  handle 
large  sets  of  satellite  data  from  a  number  of  different  platforms  and  sensors,  a  requirement 
that  has  been  and  continues  to  be  a  focus  for  continued  development.  More  recently,  new 
applications  are  being  supported  by  AIMS  that  extend  beyond  traditional  requirements  in 
satellite  meteorology  to  other  areas  of  study  within  the  Atmospheric  Sciences  Division. 
Examples  include  application  of  mesoscale  forecast  models  through  data  assimilation 
(Lipton,  1990;  Hamill,  1991),  application  of  artificial  intelligence  techniques  for  quality 
control  of  acquired  conventional  meteorological  data  (O'Donnell,  1990)  and  support  to  real¬ 
time  radar  data  collection  for  polarimetric  studies  (Metcalf,  1992).  Application-related 
support  functions  are  also  being  performed  on  AIMS  such  as  collection  of  real-time  and 
archived  satellite  and  conventional  meteorological  data,  data  reformatting  and  data  staging. 
The  popularity  and  availability  of  desktop  software  has  also  made  it  possible  for  scientists 
using  AIMS  to  prepare  publication-quality  scientific  reports  and  articles.  Finally,  AIMS 
has  expanded  to  support  functions  (through  assuming  additional  responsibilities)  that  may 
appear  unconnected  with  the  application  s-oriented  environment  of  the  system  but 
nevertheless  contribute  to  AIMS  as  a  system.  For  example,  AIMS  is  now  an  important  hub 
for  the  exchange  of  information  both  within  the  laboratory  and  with  institutions  and 
organizations  outside  the  laboratory  through  the  use  of  applications  such  as  electronic  mail 
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and  remote  file  transfer  capabilities.  AIMS  also  functions  as  a  server,  providing  file  and 
print  services  to  a  number  of  personal  computers  throughout  the  division. 

AIMS  has  evolved  over  the  last  six  years  into  a  system  that  reflects  the  initial 
motivation  behind  its  development  as  well  as  new  ad  hoc  requirements  from  an  increased 
community  of  users.  This  paper  details  the  evolution  of  AIMS,  its  role  in  support  of 
atmospheric  research  projects  within  GPA,  the  consequences  of  that  evolution,  and  some 
guidelines  and  recommendations  for  the  future. 

2 .  History 

AIMS  has  its  roots  in  the  Man  Computer  Interactive  Data  Access  System  (McIDAS) 
developed  by  the  University  of  Wisconsin  to  provide  an  interactive  capability  for  analysis 
and  display  of  conventional  and  remotely  sensed  meteorological  data.  The  Geophysics 
Directorate  (then  known  as  the  Air  Force  Geophysics  Laboratory  (AFGL))  purchased  a 
McIDAS  in  die  mid  1970's  to  support  ongoing  and  proposed  research  in  satellite 
meteorology  and  numerical  weather  prediction  within  the  Atmospheric  Sciences  Division 
(Fournier,  1982).  The  AFGL  McIDAS  included  a  real-time  GOES  ground  station 
capability,  a  connection  to  the  WB604  line  for  access  to  conventional  meteorological  data 
and  a  dialup  capability  to  acquire  Weather  Bureau  Remote  Radar  (WBRR)  data.  Based  on 
a  Harris  6024/5  minicomputer,  the  system  boasted  64K  of  core  memory,  a  single  80  MB 
removable  disk  and  two  interactive  6-bit  image  workstations  tied  to  a  custom  digital  video 
storage  system.  By  the  early  1980s  an  increasingly  large  number  of  projects  encompassing 
a  range  of  atmospheric  research  topics  were  using  the  AFGL  McIDAS  for  computer 
support.  These  included  studies  to  improve  the  satellite  portion  of  the  AFGWC  real-time 
nephanalysis  program,  processing  and  quantitative  evaluation  of  multispectral  data  from  the 
GOES  VISSR  Atmospheric  Sounder  (VAS)  and  an  assessment  of  the  use  of  interactive 
graphics  in  short-range  weather  forecasting.  By  1983  these  and  other  applications  were 
severely  taxing  the  capabilities  of  the  AFGL  McIDAS,  prompting  the  need  for  an  upgrade 
plan  to  address  user  and  application  needs  for  the  next  10  years. 

In  1983  users  of  the  AFGL  McIDAS  formulated  a  plan  to  develop  a  new  interactive 
computer  system  based  on  the  following  requirements: 

1 .  expandable  to  accommodate  increasing  amounts  of  satellite  and  other  types 
of  data  from  different  platforms  and  sensors; 

2.  facilitate  integration  of  new  data  sources; 


3.  maximize  data  visibility  and  minimize  user  impact; 

4.  facilitate  resource  (CPU,  peripherals)  expansion, 

5.  emphasize  satellite  data  handling  and  display;  and 

6.  provide  a  user-friendly  human  interface  that  supports  varying  skill  levels. 

The  system  specifications  drawn  from  these  requirements  called  for  a  distributed  system  of 
processors,  each  functionally  unique  and  connected  by  a  local-area  network.  Three  areas 
of  functional  use  were  identified;  1 )  data  ingest  for  both  real-time  and  archived  satellite, 
radar  and  conventional  meteorological  data;  2)  interactive  satellite  image  processing, 
graphical  analysis  and  data  visualization;  and  3)  batch  processing  to  support  non-interactive 
compute-intensive  applications.  For  real-time  GOES  ingest,  a  Gould  SEL  (now  Encore) 
minicomputer  was  chosen  for  its  real-time  performance  capabilities  to  handle  the  increased 
bandwidth  of  VAS  data.  Digital  Equipment  Corporation  (DEC)  MicroVAX  II  minicom¬ 
puters  were  specified  to  host  ADAGE  32-bit  imaging  subsystems  for  interactive  display 
and  processing  of  multispectral  satellite  data.  For  application  development  and  batch 
processing,  a  VAX  1 1/750  was  employed  to  exploit  its  user-friendly  development  environ¬ 
ment  and  processing  capabilities.  Although  off  the  shelf  hardware  and  software  were  used 
wherever  possible  to  minimize  development  time  and  complexity,  the  AIMS  multi-platform 
configuration  posed  problems  for  commercially  available  networking  solutions  of  the  time. 
The  AIMS  specification  for  data  access  within  the  local-area  network  called  for  a  distributed 
file  system  that  would  accommodate  different  hardware  platforms.  Unfortunately,  such  a 
capability  was  not  commercially  available  at  the  time.  Consequently,  AIMS  evolved  into 
two  networks  utilizing  the  DECnet  protocol  suite:  a  point-to-point  network  connecting  the 
Gould  with  a  "gateway”  DEC  computer  and  a  multipoint  network  of  DEC  computers. 

The  growth  and  development  of  AIMS  continued  throughout  the  mid  1980s. 
Gustafson  era/.  (1987)  described  the  physical  and  functional  configuration  of  AIMS  while 
a  companion  report  by  Kleespies  et  al.  (1987)  provided  an  overview  of  applications 
utilizing  the  new  system  at  that  time.  Since  that  time  AIMS  has  continued  to  grow  steadily 
through  the  addition  of  new  processors  for  interactive  development,  the  introduction  of 
workstations,  mass  storage  and  memory  expansions,  additional  real-time  data  acquisition 
systems  and  various  peripheral  devices.  The  number  of  applications  supported  on  AIMS 
has  also  grown  and  presently  covers  the  range  from  investigations  into  the  use  ot  numeric*! 
weather  prediction  models  for  mesoscale  forecasting  to  applied  research  directed  toward 
nephanalysis  algorithm  development  for  global  and  regional  cloud  analysis  models, 
characterization  of  tropical  cyclones  using  microwave  data  and  technique  development  for 
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retrieval  oflow-level  water  vapor  and  precipitable  water  amounts  from  multispectra] 
infrared  sensor  data. 

3.  Current  Configuration 

The  current  configuration  of  AIMS  is  summarized  in  Table  1  and  illustrated  by  the 
schematic  in  Figure  1.  AIMS  consists  of  second-,  third-  and  fourth-generation  DEC 
MicroVAX  minicomputers  and  workstations,  three  imaging  workstations  built  around 
Adage  image  processing  systems,  a  GOES  mode  AAA  ground  station  interfaced  to  an 
Encore  32/67  minicomputer,  and  NOAA/T1ROS  and  DMSP  ground  stations  interfaced  to 
Sun  workstations.  It  is  apparent  from  Table  1  that  system  expansion  has  favored  the  DEC 
architecture,  namely  VAX/VMS.  The  reason  for  this  has  been  the  ability  of  the  VAX/VMS 
architecture  to  consistently  meet  the  majority  of  the  requirements  developed  in  the  original 
upgrade  plan  and  subsequently  as  new  requirements  evolved.  The  reasons  for  this  are 
threefold.  First,  regardless  of  changes  at  the  hardware  level,  the  VMS  operating  system 
has  remained  unchanged  across  VAX  platforms  from  both  the  user  and  systems  perspec¬ 
tive.  Thus  AIMS,  for  the  most  part,  has  developed  into  a  homogeneous  network  that 
provides  a  consistent  interface  to  the  user.  Second,  advances  in  networking  in  the  late 
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Figure  1 .  AIMS  Hardware  and  Network  Configuration. 

1980s  made  it  possible  to  more  tightly  couple  VAX-based  networks  using  intelligent  mass 
storage  devices  and  highly-optimized  protocols.  A  networking  architecture  known  as 
clustering  was  adopted  by  AIMS  in  1988  to  provide  a  system-level  link  among  nodes 
(computers)  on  the  network  and  a  distributed  file  system  in  which  disks  (and  now  tape 
drives)  attached  to  any  network  node  can  be  accessed  transparently  from  any  other  node. 
Clustering  immediately  satisfied  three  of  the  requirements  in  the  upgrade  plan.  First 
transparent  access  to  disks  located  anywhere  within  the  network  meant  that  the  visibility 
(availability)  of  satellite  data  was  immediate  regardless  of  where  it  was  located.  Second, 
AIMS  could  easily  accommodate  increased  amounts  of  satellite  data  simply  by  adding 
additional  disks  within  the  network  and  configuring  them  for  cluster  access.  Third,  AIMS 


could  expand  easily  if  requirements  warranted  additional  processing  resources  by  utilizing 
an  additional  feature  of  cluster  software  that  allows  nodes  to  be  added  to  the  network 
without  incurring  the  overhead  of  having  to  manage  it  as  a  separate  system. 

Finally,  the  popularity  of  the  VMS  operating  system  among  AIMS  users  has  been 
consistent  over  the  past  ten  years.  VMS  has  a  highly  intuitive  command-level  language  with 
extensive  help  facilities.  Coupled  with  powerful  features  that  allow  easy  customization  of 
the  user  environment,  VMS  easily  accommodates  the  novice  user  as  well  as  the  expert. 

3.1  Network  Access 

The  physical  configuration  of  AIMS  is  centered  around  an  Ethernet  backbone  that 
provides  a  high-speed,  functionally  robust  network  for  DEC  systems  (refer  to  Figure  1). 
Coupled  with  cluster  software,  the  configuration  is  referred  to  as  a  Local  Area  VAX  Cluster 
(LAVC).  Third  party  software  extends  DECnet  functionality  over  the  AIMS  Ethernet  to  the 
SUN  NOAA  and  DMSP  ground  station  computers  while  a  separate  third  party 
hardware/software  package  extends  the  same  functionality  to  the  Encore  GOES  ground 
station  computer  via  a  high-speed  parallel  link. 

In  addition  to  the  access  within  the  LAVC',  AIMS  has  historically  required  access  to 
other  resources  both  within  and  outside  the  laboratory.  Early  in  its  existence,  however, 
AIMS  experienced  chronic  problems  attempting  to  communicate  at  terminal  speeds  over  the 
GP  network,  a  broadband-based  net  that  links  nearly  all  computer  systems  within  GP, 
including  a  central  computing  facility.  In  1988  these  problems  were  mitigated  when  GP 
installed  a  facility  wide  Ethernet  backbone,  a  decision  that  was  greatly  influenced  by 
requirements  of  the  Atmospheric  Sciences  Division  for  reliable,  high  speed  transfer  of 
satellite  data  to  NSI  (then  known  as  SPAN)  as  well  as  improved  connectivity  to  the  central 
computing  facility.  Today  AIMS  is  a  subnet  bridged  to  the  GP  Ethernet  backbone.  The 
GP  network,  in  turn,  provides  access  to  the  NSI  network  and  the  New  England  Academic 
Regional  Network  (N'EARnet).  Finally,  NEARnet  itself  is  a  subnet  to  the  global  computer 
network  INTERNET  that  links  nearly  all  U.S.  government  research  facilities  and  universi¬ 
ties  along  with  many  private  organizations  and  overseas  institutions.  The  GP  network  also 
serves  general  user  computing  requirements  by  providing  access  to  VAX  9000  and 
CONVEX  mainframe  computers  and  (through  a  direct  T1  satellite  link)  a  CRAY-2  super 
computer  located  in  Albuquerque,  NM.  Figure  2  shows  the  network  configuration  of 
AIMS  with  respect  to  the  GP  Ethernet  network  and  outside  networks. 
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3.2  Data  Sources 


A  description  of  AIMS  is  best  accomplished  by  examining  the  functional 
components  of  the  system,  beginning  with  data  ingest.  Figure  3  shows  the  configuration 
of  the  direct-readout  GOES  ground  station  for  the  real-time  acquisition  of  VAS  data  utilized 
by  studies  in  environmental  parameter  retrieval  and  mesoscale  analysis.  It  consists  of  an 
8m  antenna  and  associated  downlink  electronics,  demodulator,  variable-race  bit  sync  and 
frame  sync.  A  downlink  interface  converts  the  serial  stream  to  32-bit  parallel  and  provides 
handshaking  to  the  host  computer,  an  Encore  32/67  minicomputer.  The  32/67  is 
characterized  by  a  high  speed  backplane  (-26  Mbytes/sec)  and  interface  to  the  ground 
station  (3.2  Mbytes/sec)  as  well  as  the  MPX-32  operating  system  that  is  well  suited  to  real¬ 
time  data  acquisition.  Two  disk  drives  store  subsets  of  the  visible  and  infrared  earth  disk 
image  every  half-hour.  Figure  4  depicts  the  geographical  coverage  as  currently  seen  by 
GOES-7  as  well  as  a  subsection  that  represents  the  coverage  of  data  ingested  by  AIMS 
Visible  data  at  1  km  nominal  resolution  are  stored  as  brightness  counts.  Infrared  data 


T1  Safe**  Link 
toCRAV  2 


Figure  2.  AIMS/CF  Network  Configuration. 
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Figure  3. 


Figure  4. 


GOES  Groundstation  Configuration. 


Geographical  Coverage  of  the  Earth  as  Currently  Seen  by  GOES-7 
* ibpoint  Urngiiude  1 12.4  '  W).  The  Area  Above  the  Darkened  Une  is 
the  Coverage  of  Data  Ingested  by  AIMS. 
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always  include  the  l  lpm  thermal  infrared  channel  with  nominal  7  km  resolution  plus  two 
additional  channels  at  14  km  resolution  (typically  3.7, 6.7  or  12  pm).  Infrared  data  are 
stored  on  the  Encore  as  raw  10-bit  counts  related  to  radiance.  VAS  instrument 
characteristics  are  described  in  Table  2. 

For  GOES  data  to  be  generally  accessible  by  AIMS  users  it  must  be  moved  from 
the  Encore  to  a  node  that  is  part  of  the  AIMS  LA  VC.  As  shown  in  Figure  3,  this 
"gateway"  computer  is  a  MicnoVAX  II  with  storage  for  user-defined  subsets  of  GOES 
data.  The  MknoVAX  and  Encore  computers  are  connected  via  a  point-to-point  link  using 
third-party  hardware  and  software  that  provide  high-speed  parallel  communications 
between  DEC  and  Encore  computers.  The  system  is  known  as  Q-LINK  and  provides 
peripheral  sharing,  automatic  file  transfer/translation,  remote  log-on,  and  a  DECnet 
capability  known  as  Q-NET.  At  preset  time  intervals  that  coincide  with  the  completion  of 
real-time  ingest  on  the  Encore,  software  executing  on  the  MicroVAX  utilizes  Q-LINK  to 
extract  and  copy  user-defined  subsets  to  local  storage.  Within  the  extraction  process, 
infrared  data  are  converted  to  8-bit  greyshade  values  (related  to  brightness  temperature)  to 
facilitate  display  processing.  Four  times  daily  navigational  elements  are  copied  to  the 
AIMS  LAVC.  These  elements  are  required  input  to  a  generalized  mathematical  solution  to 
the  satellite/earth  coordinate  transform  used  for  earth  location  of  GOES  sensor  data. 

A  direct  readout  capability  for  NOAA  polar-orbiting  satellites  exists  on  AIMS  to 
provide  timely  visible  and  infrared  multispectral  data  primarily  for  use  in  the  development 
of  improved  cloud  algorithms  for  nephanalysis  applications  such  as  the  Air  Force  tactical 
nephanalysis  (TACNEPH)  program.  As  illustrated  in  Figure  5,  the  configuration  is  a  High 
Resolution  Picture  Transmission  (HRPT)  ground  station  developed  by  SeaSpace.  It 
consists  of  a  1.2  m  tracking  antenna,  antenna  control  unit  and  positioner,  downconverter, 
receiver,  bit  sync  and  frame  sync.  The  acquisition  system  is  hosted  by  a  Sun  Sparc 
station  II  running  the  UNIX  operating  system.  Supporting  hardware  includes  storage  for 
a  rotating  on-line  archive  to  store  the  most  recent  four  passes,  a  4  mm  DAT  drive  for  off¬ 
line  storage  and  a  user  disk  for  storing  user  data  sets  and  generated  products.  The  HRPT 
broadcast  stream  provides  sensor  data  from  the  five-channel  Advanced  Very-High 
Resolution  Radiometer  (AVHRR)  and  the  three-instrument  TIROS  Operational  Vertical 
Sounder  (TOVS).  The  AVHRR  provides  visible  and  near  IR  channels  at  0.62  and  0.86 
pm  and  three  infrared  channels  at  3.7,  10.7  and  1 1.8  |im  (Table  2).  Spatial  resolution  is 
nominally  1  km.  TOVS  provides  data  from  two  infrared  instruments  and  one  microwave 
instrument:  the  High-Resolution  Infrared  Radiation  Sounder  (H1RS),  Stratospheric 
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Satellite/ 

Channel 

Instrument  Wavelength  or  frequency  1 

_ (USD _ <OH») _ 

' _ &fi) _ 

DMSP  OLS 

Visible 

0.4  - 1.1  jim 

0.6 

Longwave  IR 

10J5  -  12.6  tun 

2.8 

DMSP  SSM/I1 

1 

19.35  GHz  V/H 

25 

2 

22.235  GHz  V 

25 

3 

37.0  GHz  V/H 

25 

4 

85  J  GHz  V/H 

12.5 

DMSP  SSM/T2 

1  (Window) 

91.5  GHz 

90 

2  (H20)2 

150  GHz 

64 

3  (H20) 

183  +/-  1  GHz 

so 

4  (H2O) 

183  +/-  3  GHz 

50 

5  (H20) 

183  +/-  7  GHz 

50 

NOAA  AVHRR 

Visible/Near  IR 

0.58  -  0.68  pm 

1.1,43 

Visible/Near  IR 

0.725  -  1.1  jtm 

1.1,  43 

Shortwave  IR 

3.55  -  3.93  jtm 

1.1.43 

Longwave  IR 

10.3  -  11.3  Jim 

1.1,43 

Longwave  IR 

lli  -  12.5  Jim 

1.1,4* 

NOAA  HIRS 

1-7  (CO2) 

13.3,  13.6,  13.9,  14.2,  14.4,  14.7,  14.9  jun 

42 

8  (Window) 

11.1  ljun 

42 

9  (Oj) 

9.71jtm 

42 

10  -  12  (H20) 

6.72,  7.33,  8.22  ji m 

42 

13-17  (N2O/CO2) 

4.23,  4.40, 4.46,  4.52.  4.57  Jim 

42 

18-19  (Window) 

3.76, 4.00  Jim 

42 

20  (Window) 

0.69  jim 

42 

NOAA  MSII 

1  (Window) 

50.31  GHz 

168 

2  (02) 

53.74  GHz 

168 

3  (02) 

54.%  GHz 

168 

4  (02) 

57.95  GHz 

168 

NOAA  SSU 

1  (CO2) 

15.0  jun 

62 

2  (CO2) 

15.0  jtm 

62 

3  (CO2) 

15.0  jtm 

62 

GOES  VAS4 

Visible 

0.55  -  0.75  jim 

1 

1  -  6,  1 1  (CO2) 

4.44,4.52,  13.31,  13.99,  14.23,  14.45,  14.71  Jim 

7,  14 

7  (H20) 

12.66  jim 

7,  14 

8  (Window) 

11.17  jim 

7,  14 

9  10  (H20) 

6.725,  7.25  jim 

7.  14 

12  (Window) 

3.94  jim 

14 

‘Channel  data  are  dual  polarized  except  22.23S  GHz  which  arc  only  vertically  polarized. 

‘Principal  absorbing  constituents  for  sounding  channels. 

^Nominal  resolution  for  all  channels  is  1. 1  km.  GAC  data  arc  available  at  4  km  reduced  resolution. 
4 Data  from  channels  3-6  and  7-1 1  are  available  at  either  7  or  14  km. 


Table  2.  Characteristics  of  Satellite  Sensor  Data  Used  on  AIMS. 
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Figure  5.  NOAA  Groundstation  Configuration. 

Sounding  Unit  (SSU)  and  Microwave  Sounding  Unit  (MSU)  (Table  2).  Together  the  three 
instruments  provide  27  spectral  channels  that  arc  used  to  obtain  vertical  profiles  of  atmo¬ 
spheric  temperature  and  water  vapor.  A  comprehensive  software  package  is  provided  with 
the  system  to  extract,  format,  calibrate  and  earth-locate  subsets  of  the  HRPT  telemetry  data. 
X-based  software  is  also  provided  for  interactive  image  display  and  processing  of  the  data. 

A  companion  system  to  the  HRPT  ground  station  provides  satellite  data  from  the 
Defense  Meteorological  Satellite  Program  (DMSP)  including  visible,  infrared,  microwave 
imagery  and  sounding  sensor  data  (Table  2).  As  shown  in  Figure  6,  the  configuration  is  a 
Real  Time  Data  (RTD)  ground  station,  also  developed  by  SeaSpace.  The  broadcast  data 
stream  provides  sensor  data  from  the  Operation  Line  Scanner  (OLS),  a  two  channel 
radiometer  with  a  visible  channel  at  0.75pm  and  an  infrared  channel  at  1 1 .55pm.  Sensor 
resolution  is  0.6  km  for  the  visible  and  2.8  km  for  the  infrared.  In  addition  to  OLS  sensor 
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Figure  6.  DMSP  Groundstation  Configuration. 

data,  the  ground  station  also  supports  two  sensors  from  the  special  sensor  suite.  The  first 
is  the  Special  Sensor  Microwave  Imager  (SSM/I),  a  seven-channel,  four-frequency 
microwave  radiometer  used  primarily  to  estimate  geophysical  parameters  of  the  earth  and 
atmosphere.  These  include  ocean  surface  wind  speed,  ice  coverage  and  age,  precipitation 
rates,  cloud  water  content,  total  integrated  water  vapor,  soil  moisture,  land  surface 
temperature,  surface  type  and  cloud  amount.  The  second  special  sensor  supported  is  the 
Special  Sensor  Temperature  (SSM/T)  Sounder,  a  seven-channel  microwave  radiometer  that 
measures  upwelling  radiation  between  50  and  60  GHz.  Channel  data  from  the  SSM/T 
Sounder  are  input  to  applied  inversion  techniques  to  estimate  temperature  profiles  of  the 
atmosphere.  Characteristics  of  both  special  sensors  are  summarized  in  Table  2. 

Unlike  the  GOES  ground  station  computer,  the  Sun  hosts  to  the  HRPT  and  RTD 
ground  stations  are  connected  directly  to  the  AIMS  Ethernet  network  (Figures  5  and  6), 
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I 

Although  it  cannot  participate  directly  as  a  clustered  node,  third-party  software  known  as 

TSSnet  allows  the  HRPT  system  to  participate  as  a  DECnet  end  node  providing  the  | 

capabilities  for  file  transfer,  remote  tog-on,  remote  job  activation  and  X  interoperability 

within  AIMS.  The  Network  File  System  (NFS),  a  network  architecture  developed  by 

SUN  Microsystems  and  similar  in  function  to  Digital's  clustering,  extends  the  HRPT 

systems  access  to  data  located  on  the  RTD  ground  station,  such  that  DMSP  data  can  be  I 

transferred  within  the  AIMS  LA  VC  without  the  need  for  the  host  workstation  to  participate 

directly  as  a  DECnet  node.  Projects  such  as  TACNEPH  use  TSSnet  to  transfer  AVHRR 

and  OLS  satellite  data  to  a  database  on  the  AIMS  LA  VC  to  take  advantage  of  existing 

processing  software.  ^ 

Conventional  meteorological  data  are  used  extensively  on  AIMS  to  support  a  wide 
range  of  applications.  These  data  are  generally  made  available  via  connections  to  two 
components  of  the  National  Weather  Service  (NWS)  Family  of  Services  (FOS).  The  first 
component,  known  as  the  Domestic  Data  Service  (DDS),  provides  coded  observations,  I 

reports,  forecasts  and  analyses  for  the  U.S.,  Canada  and  the  Caribbean.  The  DDS  is 
broadcast  as  a  serial,  asynchronous  data  stream  at  4800  baud  The  second  component  is 
known  as  the  International  Data  Service  (IDS)  and  provides  worldwide  coded  observa¬ 
tions,  reports  and  forecasts.  The  IDS  is  broadcast  as  a  serial,  asynchronous  data  stream  at  i 

1200  baud.  Figure  7  depicts  the  configuration  for  real-time  acquisition  from  this  data 
source.  The  DDS  and  IDS  lines  connect  to  serial  ports  on  a  Micro  VAX  III  with  dedicated 
on-line  storage  for  processed  conventional  reports.  The  computing  requirements  imposed 
by  this  data  source  are  quite  modest  compared  to  satellite-based  acquisition  requirements.  I 

This  means  that  a  number  of  AIMS  LA  VC  nodes  that  have  two  serial  ports  and  adequate 
disk  capacity  can  perform  this  function  should  the  designated  node  fail,  a  capability  that 
reflects  the  distributed  design  of  AIMS. 

I 

The  FOS  multiplexes  data  originating  from  different  sources,  producing  a  data 
stream  of  point,  gridded  and  tabular  data  with  varied  formats.  AIMS  recognizes,  decodes 
and  reformats  a  subset  of  data  sources  that  includes  Service  A,  synoptic,  ship  and  buoy, 

METAR,  upper-air,  manually  digitized  radar  (MDR)  and  NMC  model  guidance.  Table  3  ( 

describes  the  conventional  meteorological  data  sources  available  on  AIMS  while  Table  4 
lists  the  data  types  associated  with  each  source.  All  data  have  been  archived  to  8  mm  tape 
since  September  of  1989.  Unprocessed  conventional  meteorological  data  are  character¬ 
istically  high  in  volume  and  tow  in  information  content.  Substantial  development  over  the 
last  six  years  has  produced  generalized  applications  and  programming  utilities  that 


13 


Source 

Type 

Coverage 

Freauencv 

Service  A 

Point 

US,  Canada 

Hourly 

Surface  observations 

Synoptic 

Point 

Global 

4/8  times  daily 

Surface  observations 

METAR 

Point 

Global 

8  times  daily 

Surface  observations 

Ships/Buoys 

Point 

Global 

4/8  times  daily 

Platform  observations 

Upper  Air 

Point 

Global 

Twice  daily 

Radiosonde,  rawinsoode 
measurements 

Forecast 

Guidance 

Point 

US 

Twice  daily 

LFM  and  NGM  model  out¬ 
put.  Forecasts  for  6  hour 
intervals  out  to  48  hours 

Forecast  Model 
Output  Statistics 
(MOS) 

Point 

US 

Twice  daily 

Statistically-based  forecasts 
derived  from  the  LFM. 
Forecasts  for  6  hour 
intervals  out  to  48  hours 

Trajectory 

Forecasts 

Point 

US 

Twice  daily 

Statistically-based  forecasts 
derived  from  the  LFM. 
Includes  parcel  trajectories 
for  6  hour  intervals  our  to 
24  hours 

Lightning 

Point 

US 

Every  minute 

Location  of  cloud  to  ground 
lightning  strokes 

Manually 
Digitized  Radar 
(MDR) 

Gridded 

US 

Hourly  (on  the 
half-hour) 

Maximum  reflectivity 
reported  far  grid  box.  Also 
some  cell  characteristics. 

1  See  TaMe  4  for  a  complete  luting  of  source  data  types. 

Table  3.  Conventional  Meteorological  Data  Sources  Available  on  AIMS. 
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Table  4.  Data  SourcelType  Matrix  for  the  AIMS  Conventional  Meteorological  Database. 
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present  data  that  is  low  in  volume  and  high  in  information  content.  These  applications  are 
described  in  section  3.6. 

lightning  data  axe  the  most  recent  addition  to  acquired  sources  of  conventional  data 
(Tables  3  and  4)  and  have  already  been  utilized  to  support  the  acquisition  of  radar  data  for 
poiarimetric  studies.  As  shown  in  Figure  8,  the  physical  configuration  developed  to 
acquire  lightning  data  into  AIMS  is  unique  since  the  ingest  hardware  is  maintained 
separately  at  a  remote  location  within  GP.  The  GP  broadband  Ethernet  network  is  used  to 
provide  transparent  connectivity  from  the  lightning  ingest  facility  to  AIMS.  Lightning  data 
are  received  in  real-time  from  the  SUN Y- Albany  lightning  detection  network  and 
automatically  ingested  by  a  PC-based  turnkey  system  operated  by  the  Atmospheric 
Structures  Branch.  A  serial  connection  on  the  PC  provides  a  9600  baud  output  stream  for 
lightning  data  that  is  connected  to  a  port  on  a  local  terminal  server  which  in  turn  is 
connected  to  the  GP  broad  band  Ethernet  network.  By  employing  existing  Local  Area 
Transport  (LAT)  software  on  both  AIMS  and  the  terminal  server,  the  port  on  the  terminal 
server  appears  local  to  the  AIMS  LA  VC  node  that  requests  it  using  a  LAT  software 
configuration  utility.  Ultimately,  ingest  software  running  on  the  designated  AIMS  node 
assigns  a  connection  to  the  port  as  if  it  were  physically  attached  to  that  node.  As  shown  in 
Figure  8,  the  lightning  ingest  computer  is  a  VAX  station  2000  with  a  70  MB  disk  available 
for  lightning  data  storage.  Although  dependent  on  a  number  of  components,  this 
configuration  for  the  acquisition  of  lightning  data  provides  excellent  fail-over  capabilities  to 
any  node  in  the  AIMS  LAVC.  This  is  accomplished  by  simply  moving  the  executable 
software  to  the  new  node  and  configuring  the  port  connection  through  software. 

3.3  Data  Visualization  and  Processing 

Interactive  display  and  processing  of  single  and  multispcctral  satellite  data  are 
performed  on  three  VAX  station  3600  workstations  configured  with  Adage  3000  image 
display  subsystems  (refer  to  Figure  9).  Each  Adage  is  configured  with  a  minimum  of  4 
MB  of  image  refresh  memory,  a  32-bit  programmable  bit-slice  processor,  four  8-bit  lookup 
tables  for  8-bit  pseudo  or  24-bit  full  color  display,  an  8-bit  overlay  channel  and  a  crossbar 
switch  that  allows  the  user  to  select  any  combination  of  memory  planes  for  subsequent 
output  The  bit-slice  processes-  is  programmable  from  the  host  either  directly  in  micro  code 
or  by  using  a  higher-level  language  cross-compiler.  This  allows  basic  image  processing 
functions  such  as  histogram  creation  or  imaging  filters  to  execute  at  screen  refresh  rates 
(e.g.,  1/30  sec).  Supporting  the  Adage  and  VAX  station  computer,  each  image  processing 
workstation  has  two  monitors,  one  for  full  color  display  from  the  Adage  frame  buffers  and 


Figure  9.  Adage -Based  Workstation  Configuration. 


the  second  for  8-bit  color  image  display  and  graphics  from  the  VAX  station.  The  VAX 
station  provides  an  Ethernet  interface  to  the  AIMS  LA  VC  plus  keyboard  entry,  menu 
display  and  a  mouse  for  cursor  control.  The  VAX  station  supports  the  Graphics  Kernel 
System  (GKS)  and  the  X  windowing  system  standards. 

Visualization  of  satellite  imagery  and  analysis  results  is  one  of  the  most  widely  used 
capabilities  on  AIMS.  The  Adage  systems  combined  with  the  VAX  stations  are  well  suited 
for  this  application.  The  24-bit  full  color  capability  is  routinely  used  to  display  both  single 
channel  and  muitispectral  sensor  data  from  systems  such  as  the  AVHRR,  OLS,  VAS  and 
SSM/I.  The  overlay  channel  is  used  to  provide  additional  information  on  top  of  the 
imagery  (e.g.,  annotation,  geopolitical  boundaries,  contour  plots,  display  of  model  analysis 
results).  The  large  frame  buffers  combined  with  multiple  hardware  lookup  tables  and 
crossbar  switch  allow  for  rapid  toggling  (at  frame  refresh  rates)  between  data  stored  in 
separate  areas  of  frame  buffer  memory.  This  is  useful  for  visualizing  different  sensor 
channels,  analysis  images,  overlay  configurations,  enhancement  functions  or  any  other  data 
combination  appropriate  for  a  given  application.  The  graphics  capabilities  of  the  VAX 
stations  are  used  to  display  descriptive  or  quantitative  information  about  the  imagery  on  the 
Adage  monitor.  This  type  of  information  includes  frequency  distribution  histograms, 
enhancement  functions  or  tabulated  brightness  temperature  and  albedo  values.  Several 
applications  have  been  developed  that  use  the  function  keys  on  the  VAX  station  keyboard 
to  drive  specific  channel  and  enhancement  combinations  on  the  Adage.  Function  keys  can 
be  programmed  so  that  the  display  configuration  can  be  selected  and  changed  virtually 
instantaneously  with  the  push  of  a  key.  Thus  the  separate  capabilities  of  the  Adage  and 
VAX  station  systems  complement  each  other  to  provide  a  full  functioned,  customizable 
environment  well  suited  to  interactive  investigations. 

Less  powerful  but  more  numerous  8-bit  image  display  workstations  provide 
complementary  capabilities  for  data  visualization.  They  include  three  VAX  station  2000 
workstations  and  five  VAX  station  3100  workstations  each  configured  with  16  MB  of  host 
memory,  local  disk  storage  for  application  software  and  data  files,  color  monitor  and 
mouse.  The  X  windowing  system  has  been  adopted  on  all  workstations  as  the  default 
windowing  interface  for  file  management  and  virtual  terminal  capability  in  addition  to 
graphics  and  imaging  functions.  DEC  based  workstations  use  the  DEC  implementation 
known  as  DEC  windows  and  the  SUN  workstations  (NOAA  and  DMSP  ground  station 
computers)  incorporate  SUN  Microsystems  Open  Windows.  X  was  chosen  for  its  flexible 
client/server  architecture  coupled  with  a  network-based  design  and  its  availability  on 
different  vendor  platforms.  The  client/server  model  provides  a  means  for  dividing  an 


application  into  two  components,  the  non-display  portion  that  generally  represents  the  bulk 
of  the  application  (client)  and  the  display  portion  (server).  By  dividing  the  application 
program,  performance  can  be  improved  through  overlapping  execution  of  client  and  server 
functions.  The  network  aspect  of  X  extends  the  client/server  model  by  allowing  the  user  to 
choose  which  computer  in  the  network  is  best  suited  to  perform  each  of  the  application 
components  (e.g.,  choosing  a  high-end  computer  for  a  CPU-intensive  client).  Thus  a 
single  X  program  may  actually  be  running  on  different  (and  potentially  widely  separated) 
machines.  On  AIMS,  X  windows  has  been  used  to  provide  low-end  workstation  users 
with  transparent  access  to  higher  performance  processors  to  execute  the  CPU  intensive 
portion  of  an  application,  leaving  the  workstation  only  to  display  the  resultant  output 
Since  X  is  a  universally  accepted  de  facto  standard,  it  has  already  facilitated  the  use  of 
existing  graphics  and  imaging  applications  on  different  hardware  platforms  that  adhere  to 
the  standard.  In  addition  to  the  VAX  stations,  an  NCD  X-terminal  provides  imaging  and 
graphics  capabilities  similar  to  the  workstations  but  with  maintenance  characteristics  more 
typical  of  a  character-cell  terminal.  This  is  because  the  X-terminal  depends  on  a  remote 
host  for  CPU  processing;  only  the  X  server  program  runs  locally. 

3.4  Interactive  Development  and  Batch  Processing 

Three  multi-user  Micro  VAX  computers  provide  interactive  access  for  the  majority 
of  AIMS  users  for  application  development,  debug,  test  and  access  to  existing  generalized 
applications.  Illustrated  in  Figure  10,  they  consist  of  a  MicroVAX  3600  with  mass  storage 
for  user  space,  9-track  tape  drive,  8  mm  helical-scan  tape  drive  and  1200  baud  modem  for 
remote  access;  a  MicroVAX  3900  with  mass  storage  for  satellite  data  and  user  space  and  a 
dual-density  9-track  tape  drive;  and  a  VAX  4000-200.  Access  to  these  systems  is  primarily 
through  one  of  four  8 -port  terminal  servers  that  connect  directly  to  the  AIMS  Ethernet 
network.  In  addition  to  disk  storage  associated  with  these  systems,  seven  magneto-optical 
disk  drives  have  been  added  within  the  past  two  years  to  meet  the  increasing  demand  for 
on-line  storage  of  high  volume  satellite  and  associated  ancillary  data.  Magnetooptical 
media  are  removable  dual-sided  cartridges  with  a  capacity  of  300  MB  per  side.  On  AIMS, 
these  drives  are  configurable  as  ordinary  disk  drives  and  thus  can  be  mounted  from 
anywhere  within  the  AIMS  LAVC  as  private  volumes.  Magnetooptical  drives  compare 
favorably  with  Winchester- technology  disk  drives  for  disk  reads;  however  disk  writes  are 
approximately  40%  slower.  Three  additional  drives  were  recently  purchased  to  support 
additional  satellite  storage  requirements  for  data  intensive  programs  such  as  TACNEPH 
and  calibration/validation  of  the  SSMT2  millimeter-wave  sounder. 
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Figure  10.  Interactive  Development  and  Batch  Processing  Configuration. 


AIMS  has  a  limited  capability  for  batch  processing  to  handle  CPU  intensive  applica¬ 
tions  such  as  mesoscale  numerical  models  and  radiative  transfer  models  (e.g.  FASCODE). 
While  all  AIMS  LA  VC  nodes  have  batch  capabilities,  system  wide  batch  queues  have  been 
established  which  attempt  to  optimally  match  program  resource  requirements  with  proces¬ 
sor  capabilities.  For  example,  the  multi-user  Micro  VAX  3900  is  generally  used  for  moder¬ 
ately  CPU-intensive  applications  because  overall  its  resources  provide  the  best  match  with 
"typical"  program  requirements.  Processing  capabilities  of  the  batch  node  are  approxi¬ 
mately  three  times  that  of  the  previous  batch  system,  a  VAX  1 1/750  minicomputer. 

Beyond  the  Micro  VAX  3900,  the  laboratory’s  main  computing  center  supports  greater 
CPU-demand  computing.  A  VAX  9000  and  CONVEX  mainframe  provide  five  to  ten 
nines  the  processing  capability  of  AIMS  batch  nodes. 
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3.5  Functional  Use 


The  functional  components  of  AIMS  (data  sources,  data  visualization  and  proces¬ 
sing,  interactive  development  and  batch  processing)  together  provide  a  flexible  and  full 
featured  environment  for  the  interactive  display  and  processing  of  remotely  sensed 
meteorological  data.  Realtime  satellite  data  sources  including  GOES,  NOAA/I  lROS  and 
DMSP  provide  timely  high-quality  imagery  suitable  for  cloud  analysis  and  studies  related  to 
environmental  parameter  retrievals.  Once  transferred  to  the  LA  VC  side  of  AIMS  through 
their  respective  DECnet  links,  these  data  are  immediately  available  to  Adage,  VAX  and 
SUN  based  workstations  for  interactive  display  and  image  processing.  Additionally, 
computationally  intensive  processing  of  satellite  data  (e.g.,  RTNEPH  satellite  processor) 
not  suitable  for  processing  on  the  workstations  due  to  high  CPU  and  memory  require¬ 
ments,  can  take  advantage  of  the  AIMS  batch  node  which  also  affords  immediate  and 
transparent  access  to  the  data.  Typically,  the  results  from  batch  processing  are  displayable 
cloud  analyses  or  synthetic  imagery  that,  in  turn,  are  immediately  available  for  visualizing 
on  AIMS  workstations. 

The  common  thread  that  binds  these  functional  components  together  is  the  system 
functionality  of  the  LA  VC.  The  AIMS  Ethernet  network  provides  a  high  bandwidth, 
system -extensib'e  environment  to  accommodate  meteorological  data  sources.  Clustering 
tightly  couples  the  ..etwork  so  that  system  resources  and  data  are  readily  accessible  from  all 
workstation  and  multi-user  nodes  on  the  network.  This  provides  an  excellent  solution  to 
the  acquisition,  preprocessing  and  visualization  procedural  approach  used  by  many 
research  projects  within  the  division.  The  disk- sharing  characteristics  of  clustering  mean 
that  increased  demand  for  data  can  be  met  by  simply  adding  mass  storage  devices,  such  as 
magneto-optical,  to  the  network.  Finally,  the  VMS  operating  system,  that  runs  on  all 
AIMS  LA  VC  nodes,  provides  a  user-friendly  interactive  environment  for  application 
development  Program  development,  debugging,  testing  and  performance  measurement 
tools  designed  for  the  VMS  environment  are  also  available  on  virtually  all  AIMS  LA  VC 
systems  to  maximize  availability  of  use. 

3.6  AIMS  Applications  and  the  Development  Environment 

The  growth  and  development  of  AIMS  as  an  analysis  tool  for  research  in  die 
atmospheric  sciences  is  tighdy  bound  to  applications,  both  developed  and  acquired,  that 
exploit  the  functional  components  of  AIMS  to  facilitate  its  use.  The  VMS  development 
environment  was  adopted  early  on  as  the  foundation  for  AIMS  applications  because  of  its 


inherent  user-friendly  interface  and  the  wealth  of  tools  available  for  program  development. 
Adopting  the  VMS  environment  also  meant  that  users  would  have  a  single,  consistent  view 
of  the  system  in  which  user-developed  applications  would  take  on  the  same  command 
structure  already  familiar  to  the  AIMS  user.  The  VMS  command  language  is  known  as  the 
Digital  Command  Language  (DCL),  a  pseudo-natural  language  characterized  by  verbs  that 
form  the  basis  of  the  command  and  qualifiers  and  parameters  that  serve  to  further  define  or 
modify  a  verb's  action.  DCL  can  facilitate  the  production  of  long  verbose  commands  and 
the  development  environment  provides  abbreviation  to  reduce  command  length.  An 
alternative  to  abbreviation  is  the  use  of  symbols.  A  symbol  is  a  name  that  represents  a 
numeric,  character,  or  logical  value.  When  used  in  a  DCL  command  line,  DCL  replaces  the 
symbol  with  its  value.  Symbols  have  a  number  of  applications,  one  of  which  is  using  them 
as  synonyms.  Defining  a  symbol  as  a  command  line  (or  a  portion  of  the  command  line) 
facilitates  execution  of  die  command  because  only  the  symbol  name  needs  to  be  typed.  As 
an  example  consider  the  command  a  user  would  have  to  type  on  AIMS  to  print  a  file  (called 
OutputTxt)  to  one  of  its  printers  without  the  benefit  of  symbols: 

$  Print/Notify/Queue=LYS_Laser/Setup=LN03_80  OutputTxt 

By  defining  a  symbol  that  equates  to  the  command  line  (excluding  file  name): 

$  P  =  Print/Notify/Queue=LYS_Laser/Setup=LN03_80 

the  user  can  use  the  symbol  as  a  synonym  for  the  command  line,  thus  reducing  the  amount 
of  typing  required  to  execute  the  print  command.  The  command  line  with  symbol 
replacement  would  lode  like: 

$  P  OutputTxt  or  in  general, 

$  P  <Filename> 

Synonym  use  of  symbols  is  typically  used  to  customize  the  user  environment,  reducing 
lengthy  commands  to  short  familiar  symbols  that  will  be  used  on  a  regular  basis.  In  fact 
symbols  can  be  used  to  emulate  otter  operating  system  command  languages  such  as  the 
UNIX  Bourne  shell.  VMS  also  supports  a  feature  known  as  logicals.  Logicals  allow  the 
user  to  dynamically  map  a  physical  expression  (e.g.,  file  pathname)  to  a  logical  name.  By 
referring  to  the  logical  name  (ratter  than  the  physical  expression)  within  an  applications 
program,  reassignment  of  the  physical  expression  can  take  place  without  having  to  make 
code  changes.  Logicals  are  used  extensively  by  AIMS  applications  as  an  effective  way  to 
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address  the  location  of  data  that  potentially  may  move  from  ore  physical  location  to  another 
(e.g.,  because  of  a  hardware  failure  or  reconfiguration).  For  example  on  AIMS  ail 
conventional  meteorological  data  are  stored  in  and  accessed  from  the  physical  location: 

ARCUNQSDUCOrfFAAJData] 

where  ARCUNO  is  the  node,  DUCO  is  the  disk  and  FAA  Data  is  the  directory  location. 
Software  programs  that  make  use  of  conventional  data  could  access  the  data  by  referring 
directly  to  this  physical  location.  However  die  disadvantage  erf  using  the  physical  location 
is  dun  if  die  data  had  to  be  moved  to  a  new  physical  location,  software  programs  (possibly 
many)  would  require  code  changes.  Alternatively,  the  physical  location  is  mapped  to  a 
logical  name.  In  this  example,  the  logical  name  FAA  .Data  is  used  to  define  die  location  erf 
conventional  meteorological  data.  To  effect  the  logical  to  physical  mapping  one  would 
execute  the  command: 


$  Define  FAA _Data  ARCUNO$DUCO:[  FAA.  Data] 

If,  at  some  later  time,  die  physical  location  changes  and  the  database  administrator  updates 
the  logical  name  to: 


$  Define  FAA _Data  ARCDEV$DUAO:[FAA.Data] 

then  programs  that  refer  to  the  logical  FAA_Data  would  not  require  code  changes.  This  is 
because  the  mapping  is  dynamic,  that  is,  references  to  the  iogical  name  will  always  map  to 
the  most  recent  physical  definition. 

The  AIMS  development  environment  provides  a  diverse  set  of  software  tools 
described  in  Table  S.  Software  exists  for  code  development  in  high-level  languages, 
interactive  debugging  and  a  toed  to  measure  program  performance.  GKS  is  used  for  basic 
graphics  and  NCAR  graphics,  based  on  GKS,  provides  scientists  with  higher-level 
functions  geared  towards  applications  in  the  atmospheric  sciences  such  as  objective 
analysis  for  contour  programs  and  specialized  graph  generation.  The  following  sections 
describe  some  of  the  more  generalized  applications  developed  to  provide  the  AIMS  user 
community  with  useful  roods  for  die  research  environment. 

Applications  centered  around  processing  and  display  of  satellite  data  have  been 
developed  primarily  for  the  Adage  workstations  although  recent  efforts  have  ported  some 
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PrtMiiirt 

VAX  Fortran 
vax  r 

VAX  Debugger 

VAX  Performance  and  Coverage  Analyzer 

DEC  Graphics  Kernel  System  (GKS) 

NCAR  Graphics 

Motif/DECWindows 

DECWrite 

DECWriteCDA 

Quantum  I/O 


Scientific  Programming 
Scrmific/Sysuatn  Programming 
Application  Debugging 
Application  Performance  Analysis 
2 -D  Graphics 

Scientific  Graphics  Based  on  GKS 
X  Window  Interface 
Document  Preparation 
Document  Cravenkm/fncxxporatiori 
Pnagrammmg  interface  to  File  System 


Table  5.  Software  Tools  Available  on  AIMS. 


of  these  applications  to  low-end  workstations  and  X -terminals.  Utilities  exist  to  manipulate 
registers  and  perform  standard  functions  on  the  Adage.  Standard  functions  revolve  around 
manipulation  of  channels,  frames,  window  and  viewport,  cursor  control,  overlay  color, 
erase  and  zoom/pan.  Adage  color  lookup  tables  can  be  manipulated  interactively  as  well. 
Supported  assignments  include  linear,  bilinear,  histogram  equalization,  histogram 
matching,  multiple  lookup  tables  and  the  ability  to  save  and  restore  lookup  tables.  Image 
loading  transfers  an  image  or  image  subset  from  a  disk  file  to  Adage  frame  buffer  memory. 
Conversely,  die  image  save  function  saves  an  image  or  image  subset  from  Adage  frame 
buffer  memory  to  a  disk  file.  Another  interactive  utility  allows  the  user  to  toggle  among 
channels  and  frames  on  the  Adage  and  provides  cursor  control  to  move  and  monitor  cursor 
position.  For  applications  development,  a  library  of  image  processing  functions  has  bent 
developed  to  perform  functions  such  as  high/low  pass  filtering,  gradient  filtering  and  other 
convolution  techniques;  image  addition  and  subtraction;  geometric  and  gray  scale 
transformations;  thresholding;  and  histogram  generation. 

Application  development  for  conventional  meteorological  data  began  at  tire 
programming  level  to  provide  a  single  programming  poim-of-acoew  is  all  data  sources  and 
data  types  that  comprise  the  conventional  meteorological  database  (Table  4).  Known  as  the 
AIMS  DataBase  (ADB)  utility  (Thomason  and  Ivaldi,  1990),  the  utility  consists  of  a 
programming  interface  and  data  "drivers,"  modules  tint  extract  data  elements  for  a 
particular  data  source.  ADB  supports  geographic-based  requests  for  conventional 
meteorological  data  using  station  number,  station  ID,  Mate,  country,  latitude-longitude  box 
or  sectional  area  as  Vocation  specifiers.  It  also  supports  tiroc-seritiliasui  requests  wring  a 
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start  and  stop  time  and  time  increment  for  a  single  station.  ADB  supports  integer,  real  and 
character  string  output  formats  that  are  programmer-definable  and  imposes  no  restrictions 
on  the  amount  of  information  returned  to  the  calling  program. 

Additional  support  modules  complement  the  application  environment  for  conven¬ 
tional  data.  Like  ADB  they  provide  a  single  calling  interface  for  applications  programming 
and  adhere  to  the  VAX  calling  standards.  These  modules  are  summarized  below. 

1.  The  Station  ID  module  provides  access  to  the  conventional  meteorological  station 
database.  This  software  accepts  a  station  attribute  and  returns  the  remaining 
attributes  for  a  single  station  or  group  of  stations.  Queries  can  confine  the  station 
list  to  a  single  repotting  class  or  only  those  stations  that  report  observations  on  a 
"regular"  basis. 

2.  The  AIMS  Map  Library  converts  a  coordinate  or  array  of  coordinates  from  one 
projection  to  another.  Supported  projections  include  latitude-longitude,  Mercator, 
polar  stereographic,  Lambert  conformal  and  spin-stabilized  GCMES .  The  capability 
also  exists  to  convert  absolute  coordinates  to  relative  coordinates  for 
transformations  associated  with  gridded  fields. 

3.  Spatial  objective  analysis  software  provides  a  means  of  determining  a  uniform 
gridded  representation  of  a  data  field  from  randomly  spaced  data  points.  Analysis 
methods  are  based  primarily  on  empirical  techniques  including  weighted 
interpolation  and  spline  fit  The  analysis  includes  a  first-guess  stage  to  initialize 
grid  points;  supported  methods  are  simple  zeroing,  arithmetic  mean,  area-weighted 
mean,  planar,  and  median  filter.  Empirical  interpolation  methods  are  based  on  either 
Barnes  (1964)  or  Cressman  (1939)  techniques. 

4.  Support  libraries  include  the  AIMS  Library  Utility,  a  collection  of  software 
modules  that  compute  derived  meteorological  data  types,  and  a  dock  library  that 
provides  routines  for  computing  date  and  time  information  in  character  string,  binary, 
integer  binary  and  integer  julian  formats. 

Appendices  A  through  D  contain  functional  descriptions  of  the  most  commonly  used 
routines  including  ADB,  Station  ID,  Map  Transform  and  the  clock  library. 

The  completion  of  ADB  and  assodated  modules  and  libraries  fadlitated  develop¬ 
ment  of  generic  and  flexible  list,  plot,  and  analysis  applications.  Appendix  E  provides  a 
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synopsis  of  each  application  along  with  example  output  produced  by  its  execution.  All 
applications  utilize  the  DCL  calling  interface  for  activation  to  comply  with  the  interactive 
environment  already  familiar  to  the  user.  Graphics-oriented  plot  and  analysis  applications 
are  based  on  GKS,  which  supports  many  output  devices  on  AIMS  including  LN03  laser 
printers,  POSTSCRIPT,  an  ink-jet  printer,  graphics  terminals  and  X  devices.  An 
extension  to  the  development  environment  is  the  use  of  the  VMS  help  facility  to  document 
command-level  use  of  developed  applications.  The  help  facility  is  also  used  to  provide 
first-time  users  with  information  about  AIMS  and  a  description  of  its  resources  including 
archive  storage,  disk  storage,  printers,  the  batch  environment  and  backup  procedures. 

3.7  System  Integrity  and  Reliability 

System  integrity  and  reliability  of  hardware,  software  and  data  are  primary  concerns 
of  AIMS  users.  Several  measures  have  been  taken  to  minimuse  down  time  and  reduce  data 
loss.  First,  critical  hardware  is  covered  by  a  third-party  maintenance  contract  that  requires 
response  within  24  hours  of  notification.  Spare  equipment  is  on  hand  to  provide  interim 
solutions  to  the  24  hour  response  window  of  the  maintenance  contract.  They  include  a  disk 
to  shadow  one  of  the  two  major  user  disks  of  the  system  and  redundant  9-track  tape  drives 
for  1600  bpi  use.  Second,  custom  components  not  covered  by  maintenance  generally  have 
spares  available  to  protect  against  equipment  failure.  They  include  the  GOES  ground 
station  receiver  and  DLI  and  QLINK  interfaces.  In  general,  AIMS  peripherals  are  multiply 
configured  not  only  to  meet  increased  user  demand  but  also  to  provide  a  minimum  configu¬ 
ration  should  one  or  more  components  fail.  Multiple  components  include  laser  printers, 
dual-density  9-track  tape  drives,  8  mm  tape  drives  and  magneto-optical  disk  drives. 

Finally,  Uninterruptible  Power  Supplies  (UPS)  for  all  AIMS  nodes  have  been  installed  to 
protect  AIMS  from  potential  damage  caused  by  blackouts,  brownouts,  lightning  and  line 
surge.  One  of  the  features  of  the  UPS  systems  is  a  computer  communications  port  that 
facilitates  the  orderly  shutdown  of  computer  systems  during  prolonged  power  loss.  This  is 
an  important  feature  for  systems  such  as  AIMS  that  have  a  distributed  file  system. 

The  day-to-day  computer  operations  of  AIMS  are  comprised  of  various  tasks,  some 
of  which  address  data  integrity.  Full  backup  of  user  data  occurs  weekly  utilizing  a 
systematic  rotation  procedure  that  employs  three  sets  of  archive  tapes.  Data  loss  is  limited 
to  one  week  at  worse  while  data  recovery  extends  to  the  previous  three  months.  System 
files  are  backed  up  every  few  months.  GOES  data  are  not  archived  on  a  regular  basis 
primarily  because  of  the  volatility  and  enormous  volume  of  data  available.  Rather,  GOES 
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data  are  archived  on  an  as-needed  basis  for  regions  of  interest  that  satisfy  a  particular  need. 
Conventional  meteorological  data,  including  lightning  data,  are  archived  bi-weekly  and  then 
purged  from  the  system  to  minimize  storage  requirements.  Polar-orbiting  satellite  data 
from  selected  passes  of  NOAA-11  and  12  and  OMSP  F10  and  FI  1  satellites  are  automati¬ 
cally  archived  to  4  mm  DAT  tape  daily.  From  a  software  perspective,  maintenance  and 
upgrade  reteases  of  the  operating  system  and  layered  products  are  typically  installed  after 
careful  review  to  assess  the  benefit/impact  of  performing  the  upgrade.  Maintenance 
releases  are  provided  solely  for  bug  fixes  while  upgrades  (major  and  minor)  usually  add 
functionality  to  existing  software. 

4.  AIMS  Support  to  Atmospheric  Research 

The  design  philosophy  for  AIMS  emphasizes  user  needs  and  requirements  over 
systems  engineering  considerations.  This  design  philosophy  is  reflected  in  many  of  the 
system  components  including  the  choice  of  operating  system,  the  large  number  of 
individual  workstations,  the  emphasis  on  interactive  capabilities  and  most  significantly,  in 
the  distributed  nature  of  the  system.  In  order  to  understand  AIMS  it  is  necessary  to  under¬ 
stand  the  types  of  applications  it  was  developed  for.  In  the  six  plus  years  since  its  incep¬ 
tion,  tire  system  has  been  used  to  support  a  large  number  of  different  applications.  White 
scientifically  distinct,  many  of  these  have  shared  a  common  requirement  for  processing 
large  amounts  of  satellite  sensor  data  in  an  interactive  environment.  The  volume  and 
unique  processing  requirements  imposed  by  the  data  drove  many  of  the  system  design 
considerations.  The  interactive  aspect  is  one  that  has  served  the  research  needs  of  the  users 
especially  well  It  is  ideally  suited  to  the  iterative,  trial-and-error  approach  that  is  common 
to  many  research  problems.  In  this  section  we  review  the  scientific  applications  that  have 
been  supported  by  AIMS. 

4.1  Image  Processing  for  Data  Visualization  and  Interaction 

An  early  project  on  AIMS  investigated  the  usefulness  of  interactive  image  proces¬ 
sing  as  a  diagnostic  and  analytical  tool  for  interpretation  of  satellite  imagery.  As  a  result  of 
this  investigation  many  of  the  current  image  processing  and  display  capabilities  available  on 
AIMS  were  developed.  For  effective  acquisition  and  processing  of  multispectral  imagery 
from  the  DMSP  OLS  and  SSM/I,  NOAA  AVHRR,  and  GOES  VAS  sensors,  and  to  more 
fully  exploit  these  data  sources  for  cloud  analysis  and  other  meteorological  applications,  an 
optimal  satellite  data  processing  capability  was  developed  to  provide  a  systematic  and 
integrated  approach  to  manipulation  of  the  data.  This  approach  was  also  successfully 


applied  to  products  derived  from  objective  analysis  and  interpretation  of  digital  satellite  Mid 
other  meteorological  data  (e.g.,  gridded  cloud  amount  and  altitude,  sounding  profiles). 
Interactive  image  processing  has  been  used  extensively  to  maintain  a  qualitative  control  of 
analyses  accuracy  and  data  quality  through  manual  examination  of  synthetic  imagery 
produced  from  derived  products.  Discontinuities  or  anomalous  values  are  quickly  and 
easily  detected  in  the  imagery  data  and  visual  comparisons  between  initial  data  fields  Mid 
analysis  products  are  useful  for  characterizing  algorithm  performance.  Aspects  of  the 
integrated  processing  and  analysis  approach  include  graphical  display,  image  processing, 
interactive  analysis  and  database  management 

As  described  in  section  3.3,  fundamental  image  processing  and  display  functions 
such  as  contrast  enhancements,  convolution  filtering,  and  pseudo/full  color  displays  are 
available  on  the  image  processing  workstations.  However,  new  and  upgraded  techniques 
that  exploit  the  advanced  capabilities  of  single-user  workstations  now  available  on  AIMS 
are  being  developed  in  response  to  specific  research  requirements.  For  example  recent 
work  using  full  color  imaging  for  display  and  interpretation  of  multispectral  imagery  has 
shown  considerable  promise  both  as  an  interactive  image  interpretation  tool  and  for 
qualitative  evaluation  of  potential  new  nephanalysis  algorithms.  Synthetic  imagery  derived 
from  either  manual  or  automated  analysis  techniques  offer  potential  as  ground  truth  for 
nephanalysis.  In  general,  graphical  display  capabilities  are  varied  and  non- standardized; 
however,  on  AIMS  the  need  for  graphical  display  as  a  visualization  tool  is  universal. 

Typical  meteorological  applications  include  optimum  interpolation  and  objective  analysis, 
linear  cross-section  analysis,  atmospheric  (vertical)  profile  representation,  data  plotting  on 
standard  map  or  satellite  projections,  regression  analysis,  and  curve  fitting.  Ongoing 
development  of  advanced  image  processing  and  display  capabilities  complements  virtually 
all  aspects  of  satellite  cloud  and  precipitation  research  being  performed  within  the  Satellite 
Meteorology  Branch. 

4.2  Objective  Nephanalysis 

While  many  applications  are  supported  on  AIMS,  the  most  significant  in  terms  of 
resource  allocation  (e.g.,  CPU  time,  mass  storage,  memory,  image  display  and  graphics)  is 
cloud  analysis.  Nephanalysis  work  within  the  Satellite  Meteorology  Branch  predates  AIMS 
(see  for  example  Valovcin,  1978;  Bunting  and  Fournier,  1980;  d'Entremont  etal.,  1982; 
Bunting  et  al 1983)  and  was  one  of  the  principal  drivers  for  the  original  system 
specifications.  Traditionally  cloud  research  has  concentrated  cm  global  nephanalysis  from 
visible,  infrared,  and  multispectral  satellite  sensor  data,  generally  in  support  of  the  Air  Force 
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RTNEPH  operational  model  (d’Entremont,  1986;  d'Entremont  etal.,  1989a;  d’Entremont 
et  al.,  1989b;  Griffin  and  Thomason,  1990;  Barker  Schaaf  et  al.,  1990;  d'Entremont  et  al ., 
1990  and  Ward  et  al.,  1992).  More  recently  this  has  been  expanded  to  include  the  effect  of 
retrieved  temperature  and  moisture  profiles  and  other  environmental  parameters  from 
microwave  imager  channels.  In  the  past  few  years  nephanalysis  work  has  focused  on 
development  of  a  new,  regional  or  theater-scale  cloud  model  for  use  iar*  Ideal  applications 
(Isaacs  and  Gustafson,  1991;  Gustafson  and  d'Entremont,  1992).  Nephanalysis  techniques 
under  investigation  rely  on  both  the  spatial  and  spectral  characteristics  of  multispectral 
satellite  sensor  data.  Cloud  detection  is  performed  through  interpretation  of  spectral 
characteristics  of  cloud  surfaces  relative  to  background  or  atmospheric  contributions.  Cloud 
layer  analyses  are  performed  through  segregation  of  the  spatial  characteristics  of  cloud 
layers.  AIMS  capabilities  for  data  acquisition,  data  handling  and  manipulation,  batch 
processing,  and  image  processing  and  display  are  used  extensively  for  nephanalysis  wotk. 

In  addition  to  cloud  detection  work,  AIMS  is  also  used  to  support  development  of 
an  innovative  technique  for  determining  cloud  microphysical  properties  using  daytime  near- 
infrared  middle-wavelength  (MWIR)  infrared  radiances  from  geosynchronous  satellites. 
Since  at  MWIR  wavelengths  upwelling  radiances  from  water  clouds  are  a  combination  of 
emitted  thermal  and  reflected  solar  components,  a  simple  method  is  used  to  first  remove  the 
thermal  effects.  The  remaining  scattered  solar  radiances  can  be  used  to  determine  the  mode 
radius  of  the  cloud  particles.  The  method  is  presently  being  tested  using  GOES  VAS  data 
that  arc  received  in  real-time  on  AIMS.  In  conjunction  with  the  GOES  investigation,  a 
theoretical  study  was  also  performed  which  determined  that  if  an  interferometer  were 
available  on  a  geosynchronous  satellite,  both  the  mode  radius  and  the  optical  depth  could  be 
determined  The  theoretical  studies  make  use  of  a  polydispersion  Mie  code  described  by 
Longtin  and  Shetde  (in  press)  and  a  discrete  ordinate  radiative  transfer  model  described  by 
Stamnes  etal.  (1989). 

4.3  Composite  Satellite  Image  Display 

A  technique  known  as  Composite  Image  Display  (CID)  was  developed  on  AIMS  to 
simulate  a  full  color  (24-bit)  multispectral  image  display  on  8-bit  color  systems.  CID 
combines  the  spectral  information  from  two  or  three  channels  of  data  into  a  single  image 
product  in  which  colors  are  used  to  highlight  areas  of  primary  meteorological  interest  to 
users  such  as  operational  forecasters.  Full  color  techniques  were  originally  applied  at  PL 
using  the  32-bit  Adage  image  processing  systems.  These  techniques  have  been  commonly 
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used  on  AIMS  to  interpret  data  from  multi  spectral  instruments  like  the  AVHRR  for 
applications  such  as  detection  of  low  clouds  and  fogs  at  night  and  identification  of  thin 
cirrus  ami  contrails.  Daytime  detection  of  clouds  is  also  enhanced.  With  CED  it  is  possible 
to  combine  multispcctral  data  and  display  results  comparable  to  high-end  24-bit  display 
systems  on  relatively  inexpensive  and  commonly  available  8-bit  workstation  computers. 
CID  technology  has  been  used  by  researchers  and  operational  meteorologists  at  the  Air 
Force  Global  Weather  Central;  European  Forecast  Unit,  Detachment  13, 2nd  Weather  Wing 
at  Traben-Trarbach,  Germany;  and  DoD  contractors  such  as  Harris  Corporation,  Aerospace 
Corporation,  and  Lockheed.  It  is  currently  in  operational  use  at  the  German  Military 
Geophysical  Office  in  Traben-Trarbach.  For  details  on  the  CID  composite  simulation 
technique,  see  Thomason  and  d'Entremont  (1992). 

4.4  Passive  Microwave  Remote  Sensing 

Microwave  imagery  data  from  the  DMSP  Special  Sensor  Microwave/Imager 
(SSM/I)  are  being  used  to  study  the  characteristics  of  tropical  cyclones  occurring  in  the 
western  North  Pacific.  The  SSM/I  is  of  particular  value  in  obtaining  information  on  cloud, 
precipitation,  and  wind  speed  distributions  in  these  storm  systems.  Analysis  of  derived 
brightness  temperature  data  is  being  used  to  develop  algorithms  for  identifying  storm 
features  such  as  the  distribution  and  extent  of  most  intense  convective  activity,  location  of 
storm  center  (eye),  and  estimates  of  storm  dimension  and  intensity.  SSMA  data  are 
received  in  real-time  at  the  AIMS  DMSP  ground  station  and  on  tape  from  the  U.S.  Navy 
for  locations  in  the  Pacific. 

In  late  1991  the  SSM/T-2  moisture  sounding  instrument  was  first  launched  on 
board  the  DMSP  F-l  1  satellite.  PL/GPAS  is  conducting  the  instrument  calibration  effort  as 
part  of  the  Air  Force  caUbradon/validation  study  that  is  bang  performed  prior  to 
designating  the  new  sensor  as  operational.  All  data  storage,  handling  and  analysis  for  this 
program  is  being  performed  on  AIMS.  The  initial  phase  of  the  program  is  to  verify  the 
instrument  calibration  with  the  ultimate  goal  to  determine  how  accurately  estimates  of  the 
vertical  distribution  of  atmospheric  water  vapor  can  be  retrieved  from  the  sensor  data. 
Diverse  databases,  such  as  the  satellite  sensor  data,  radiosonde  and  surface  observations, 
and  NASA  aircraft  measurements,  are  being  collected,  merged  and  collocated.  Radiative 
transfer  models  are  being  used  to  calculate  expected  instrument  brightness  temperatures 
from  radiosonde  and  surface  observations.  PL/GPAS  also  participated  in  die  calibration 
study  for  the  SSM/I  instrument  following  its  initial  launch  on  the  F-8  satellite  in  1987 
(Hollinger,  1991;  Gustafson  and  Felde,  1989). 


To  achieve  global  coverage  from  microwave  sounding  instruments,  one  proposal 
has  been  to  increase  the  scanning  angle  on  future  sensors.  However,  resulting  large 
incidence  angles  could  impact  the  accuracy  of  geophysical  parameter  retrieval  algorithms. 
The  gross  effect  of  high  angle  measurements  is  an  increase  in  the  atmospheric  path  sampled 
due  to  the  cosine  dependence  of  the  optical  thickness  on  air  mass  factor.  Generally,  an 
increase  in  die  atmospheric  path  will  enhance  sensitivity  to  atmospheric  parameters  (e.g., 
water  vapor  and  cloud  liquid  water)  at  die  expense  of  retrieved  surface  parameters  (e.g., 
surface  emissivity  and  sea  surface  wind  speed).  A  study  is  currently  underway  to 
investigate  the  physics  involved  with  viewing  the  atmosphere  and  geophysical  surfaces  at 
large  incidence  angles  with  passive  microwave  sensors.  The  investigation  consists  of  three 
parts:  (1)  development  of  appropriate  simulation  tools,  (2)  assessment  of  the  impact  of 
large  viewing  angles  through  geophysical  parameter  retrievals  using  simulated  data  at  large 
viewing  angles,  and  (3)  extending  existing  capabilities  for  modeling  microwave  surface 
emissivity  properties  to  large  angles  and  higher  frequencies.  Data  simulations  will  require 
extensions  to  the  RADTRAN  radiative  transfer  model  previously  developed  at  the  Phillips 
Lab.  AIMS  is  being  used  far  all  phases  of  the  project  including  software  development  and 
testing  as  well  as  the  actual  model  runs. 

4.5  Satellite/Model  Coupled  Mesoscale  Analysis 

AIMS  has  been  employed  to  run  a  mesoscale  weather  analysis  system  in  which 
numerical  interpretation  of  satellite  data  is  coupled  with  integration  of  a  numerical  model 
(Upton  and  Vonder  Haar,  1990).  The  satellite  provides  input  data  for  the  model  and  the 
model  provides  initial-guess  data  for  retrieving  meteorological  information  from  satellite 
radiances.  The  direct  product  of  the  system  is  a  four-dimensional  mesoscale  analysis. 
Experiments  have  focused  on  understanding  regionalization  of  convective  cloud 
development,  and  have  incorporated  satellite  data  on  water  vapor  concentrations,  ground 
surface  temperatures,  and  radiative  characteristics  of  clouds  (Lipton,  1990). 

5.  Future  of  AIMS 

Short  to  intermediate  term  needs  for  AIMS  are  usually  planned  on  a  yearly  basis 
and  address  general  as  well  as  project-specific  requirements  for  hardware,  software  and 
service  improvements  and  additions.  Current  needs  are  discussed  below.  Long -range 
planning  for  AIMS  has  net  been  adequately  addressed  since  the  time  of  its  inception. 
Subsequent  sections  describe  some  of  the  factors  that  have  shaped  the  current  AIMS 
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configuration  and  where  AIMS  is  headed,  and  suggest  guidelines  and  recommendations  far 
future  (Hanning. 

5.1  Short  Term  Needs  -  Systems  and  Services 

Short  term  needs  of  the  system  need  to  be  addressed  to  insure  the  continued  use  of 
AIMS  as  a  system  designed  to  support  the  atmospheric  research  community  through 
acquisition,  processing  and  display  of  remotely  sensed  meteorological  data.  The  Adage- 
based  workstations  that  provide  AIMS  with  high-end  image  processing  capabilities  are  in 
need  of  upgrading.  The  hardware  is  close  to  10  years  old,  maintenance  is  not  available  and 
spare  parts  are  difficult  if  not  impossible  to  obtain.  Rom  a  software  perspective, 
applications  developed  over  the  past  six  years  to  provide  users  an  interactive  interface  to 
Adage  capabilities  have  been  driven  primarily  by  project-specific  needs,  resulting  in 
multiple  and  somewhat  redundant  utilities.  Consequently  a  generic  interactive  interface  to 
die  Adage  based  on  a  set  of  user-defined  core  requirements  has  never  emerged.  Addition¬ 
ally  the  Adage  is  the  only  workstation  architecture  on  AIMS  that  does  not  support  the  X 
windowing  system.  This  is  a  distinct  disadvantage  for  the  Adage  because  X-based  applica¬ 
tions  for  high-end  imaging  are  now  available  on  the  commercial  market.  It  is  also  a  dis¬ 
advantage  for  AIMS  because  it  creates  an  undesirable  dual  workstation  environment.  The 
selection  of  a  successor  to  the  Adage  must  obviously  meet  the  minimum  requirements  that 
the  Adage  now  provides  in  hardware  and  that  the  base  of  developed  applications  provides 
in  functionality.  Support  for  a  standard  such  as  X  will  provide  users  a  single  consistent 
workstation  environment  across  operating  systems  and  hardware  platforms.  X  would  also 
facilitate  die  development  of  a  generic  display  and  processing  environment  in  which  lower- 
end  workstations  would  share  a  subset  of  the  capabilities  of  high-end  workstations. 

There  is  also  a  need  to  provide  high  quality  black-and-white  and  color  hard  copy 
output  for  the  Adage  workstations.  From  an  evaluation  of  current  print  technologies, 
thermal -dye  sublimation  appears  superior  in  image  reproduction  and  coles'  fidelity. 
Unfortunately,  these  printers  are  still  relatively  new  to  the  market  as  reflected  by  the  lack  of 
integrated  solutions  for  various  computer  platforms  and  limited  support  for  POSTSCRIPT. 
When  a  viable  solution  for  AIMS  is  available  this  capability  will  complete  the  general 
upgrade  requirement  for  image  processing  and  display. 

Finally,  the  need  for  a  system  cm  AIMS  that  can  serve  computationally  intensive 
tasks  has  been  discussed  and  debated  for  some  time.  Existing  applications  that  tend  to  be 


computationally  intensive  include  automated  cloud  analysis,  radiative  transfer  calculations 
and  limited  numerical  modeling  although  actual  use  has  been  infrequent.  Traditionally 
these  types  of  applications  have  been  run  on  higher-end  systems  located  at  the  central 
computing  facility  but  this  has  created  problems  in  making  the  datasets  that  normally  reside 
on  AIMS  available  to  these  systems.  One  short-term  solution  that  would  facilitate  use  of 
mainframe  systems  in  die  lab  is  a  capability  that  already  exists  within  the  lab  but  has  not 
been  exploited.  It  is  a  DEC  product  known  as  Distributed  File  System  (DFS)  and  it 
provides  a  subset  of  clustering  capabilities  for  DECnet  networks.  DFS  could  be  used  to 
extend  the  existing  GP  Ethernet  backbone  to  provide  a  tightly  coupled  network 
configuration  between  a  dedicated  AIMS  disk  containing  die  required  datasets  and  a 
mainframe  machine,  such  as  the  VAX  9000,  to  run  the  program. 

5.2  Short  Term  Needs  -  Software  and  Applications 

The  need  for  a  comprehensive  graphics  software  package  that  can  satisfy  the 
spectrum  of  needs  from  simple  interactive  plotting  of  spreadsheet  data  to  support  for 
sophisticated  program-based  objective  analysis  applications  has  been  universal  among 
AIMS  users  but  difficult  to  fulfill.  GKS-based  products  from  DEC  and  NCAR  partially 
satisfy  the  need,  but  even  these  products  have  problems  such  as  poor  documentation  and 
inadequate  support  for  problem  resolution  and  bug  fixes.  Other  interactive  solutions  are 
currendy  being  used  in  a  limited  capacity.  PV-WAVE  from  Precision  Visuals  is  an 
interactive  software  system  used  for  analysis  of  scientific  data.  PV-WAVE  installs  on 
existing  VAX  stations  running  X  windows  and  provides  a  fourth-generation  programming 
language  and  a  plotting/image  display  package.  PV-WAVE  is  currently  being  used  to 
support  numerical  model  assimilation  studies  using  radar  data.  On  personal  computers, 
products  such  as  Quattro  Pro  and  Harvard  Graphics  are  used  to  interactively  produce 
simple  line  plots  of  scientific  data  in  spreadsheet  format.  The  benefit  of  these  types  of 
packages  is  the  relative  ease  in  producing  both  complex  and  simple  plot  displays 
interactively,  thus  avoiding  the  often  tedious  procedure  of  developing  a  software  program 
to  provide  the  same  capability. 

Commercial  hardware  and  software  solutions  for  integrating  data  sources  into  the 
AIMS  environment  are  often  incomplete  and  require  development  effort  to  facilitate  its  use 
and  provide  a  cohesive  system.  In  the  case  of  GOES  data,  current  capabilities  are  limited  to  ] 

a  24-hour  rotating  archive  of  visible  and  multi  spectral  infrared  imagery  that  arc  transferred  j 

to  the  LAVC  side  of  AIMS  following  ingest.  User-defined  image  subsets  are  fixed  with  j 

respect  to  geographic  extent  and  data  files  must  be  managed  manually,  typically  by  storing  j 
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files  in  different  directory  structures.  Improvements  to  handling  and  managing  GOES  data 
are  currently  underway.  Software  is  being  developed  to  provide  the  AIMS  LA  VC  an 
interactive  capability  to  schedule  the  real-time  GOES  ingest  as  well  as  request  data  from  a 
database  system  that  manages  data  automatically  on  both  die  ingest  computer  and  the  LAVC 
gateway  node.  A  formal  database  for  GOES  data  will  also  provide  the  capability  to 
interactively  query  data  based  on  data  characteristics  rather  than  depending  on  file  names  to 
describe  file  contents. 

The  lower-end  8-bit  workstations  on  AIMS  total  nine  at  present  and  are  somewhat 
under  utilized  due  to  the  lack  of  available  software  to  exploit  the  satellite  and  conventional 
data  processing  capabilities  of  AIMS.  Software  that  is  available  generally  takes  the  form  of 
a  menu  or  screen-based  utility  that  must  be  terminated  in  order  far  the  user  to  perform  any 
other  interactive  functions.  Thus  it  is  the  utility  that  is  interactive  and  not  the  workstation 
environment.  An  interactive  workstation  environment  must  provide  a  software  framework, 
preferably  based  on  X,  that  can  manage  the  asynchronous  execution  of  multiple  concurrent 
applications  that  share  workstation  resources.  Such  an  interactive  environment  (although 
not  workstation-oriented)  has  been  implemented  on  the  Encore  GOES  ground  station 
computer  and  more  recently  a  limited  capability  has  been  demonstrated  on  AIMS  8-bit 
workstations. 

In  addition  to  the  domestic  and  international  data  services  under  the  FOS,  the 
Numerical  Product  Services  (NPS)  is  also  available,  containing  analyses  and  forecasts 
derived  from  NMC  LFM,  NGM  and  global  spectral  models.  The  data  arc  binary  and  are 
formatted  in  WMO  G Ridded  Binary  (GRIB)  format  prior  to  transmission.  Data  are 
transmitted  in  synchronous  mode  (as  opposed  to  asynchronous  mode  used  by  all  other  data 
services)  using  the  X.25  protocol  standard  and  thus  will  require  a  synchronous  port 
connection  on  AIMS.  The  availability  of  software  to  handle  X.25  transmission  and  the 
GRIB  format  will  require  further  investigation;  however,  plans  to  incorporate  this  data  into 
the  AIMS  conventional  database  for  interactive  and  programming  access  have  already  been 
outlined.  The  plan  calls  for  the  integration  and  management  of  gridded  data  from  this 
service  (as  well  as  the  current  capability  to  produce  gridded  fields  from  raw  data)  through 
development  of  a  grid-point  database  and  management  utility. 

5.3  Long-Range  Plans  and  Goals 

From  a  systems  perspective,  AIMS  has  been  shaped  not  only  by  the  original 
requirements  developed  for  the  acquisition  and  processing  of  meteorological  data  but  also 
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by  additional  ad-hoc  requirements,  both  well-  and  ill-defined  with  respect  to  matching 
needs  to  AIMS  and  its  resources.  AIMS  has  become  increasingly  popular  as  a  system  that 
supports  a  wide  range  of  needs  and  is  convenient  to  use.  This  can  be  attributed,  in  part,  to 
the  matted  improvement  of  computer  connectivity  made  possible  by  off-the-shelf  computer 
networking  ha.dware  and  software  that  emerged  in  the  late  1980s.  It  is  also  a  reflection  of 
the  flexible  and  extensible  nature  of  AIMS  that  has  permitted,  if  not  encouraged,  the 
expansion  of  the  system  into  the  diverse  areas  that  it  now  supports.  To  understand  where 
AIMS  is  headed  it  is  important  to  understand  how  AIMS  is  currently  used 

In  addition  to  the  primary  research-driven  functions,  AIMS  also  performs  functions 
characteristic  of  a  general-purpose  computing  system.  It  is  an  important  hub  for  the 
exchange  of  information,  primarily  through  the  use  of  electronic  mail,  both  within  the 
\  ‘-juratory  and  to  outside  networks.  It  is  used  for  computer  training,  data  entry,  word 
processing,  desktop  publishing  and  supports  a  generic  account  that  provides  a  simple 
interface  to  AIMS  general  purpose  meteorological  applications  that  is  geared  to  the  novice 
user.  AIMS  provides  disk  and  print  services  to  a  growing  base  of  PC  users  that  are 
beginning  to  perform  many  of  the  data  processing  and  display  functions  normally 
associated  with  AIMS  workstations.  AIMS  is  also  starting  to  expand  beyond  the  long-held 
DEC  computer  architecture  to  support  other  platforms  such  as  SUN,  IBM  and  Apple,  each 
requiring  individual  administration  that  is  complicated  by  the  need  to  integrate  these 
platforms  into  the  existing  LA  VC  environment. 

From  a  physical  standpoint,  AIMS  has  grown  dramatically  from  its  modest  begin¬ 
nings  and  this  has  introduced  logistical  issues  for  system  administration  and  management 
that  did  not  exist  six  years  ago.  These  issues  need  to  be  addressed  as  part  of  long  range 
planning,  particularly  in  light  of  recent  trends  toward  heterogeneous  networking  (i.e.,  a 
network  with  a  significant  mix  of  computers  from  different  vendors),  individualized 
computing  on  the  desktop  and  general-purpose  computing.  The  expansion  of  these  three 
areas  without  formal  planning  could  endanger  the  effective  use  of  AIMS  and  render  the 
system  unmanageable.  Hie  following  guidelines  are  presented  as  a  basis  for  long  range 
planning  for  AIMS: 

1 .  Goals  must  be  clearly  defined  before  long  range  planning  can  proceed.  If 
current  trends  and  use  of  the  system  reflect  new  or  different  goals  they  should 
be  formally  identified. 
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2.  There  needs  to  be  a  balance  between  what  AIMS  can  do  and  what  can  be 
supported  based  on  current  staffing.  Additional  staffing  may  be  necessary 
baaed  on  current  growth  trends. 

3.  There  needs  to  be  improved  analysis  of  matching  project  requirements  to 
laboratory  resources  before  the  start  of  the  project 

4.  Criteria  for  establishing  system  needs  must  be  formulated  (e.g.,  capabilities 
should  be  added  with  the  overall  community  of  users  and  system  goals  in  mind; 
capabilities  should  be  added  on  a  per-prpject  basis,  independent  of  others). 

Historically  AIMS  has  been  primarily  a  homogeneous  system  composed  of  DEC 
computers  that  form  a  tightly  coupled  network  with  LAVC  software.  However  platforms 
from  other  vendors,  particularly  in  the  UNIX  workstation  market,  are  now  being  consider¬ 
ed  for  CPU  processing  capabilities  and  hardware/software  solutions  for  image  processing. 
Careful  thought  about  system  integration  issues  must  be  given  if  AIMS  is  to  move  closer  to 
a  heterogeneous  network.  One  way  to  address  these  issues  is  through  the  use  of  de  facto 
and  ANSI/IEEE  standards.  X-Terminals  provide  a  viable  alternative  to  workstations  for 
low-end  image  and  graphics  processing.  Because  they  implement  X  directly  and  support 
multiple  networking  protocols  (e.g.  DECnet  and  TCP/IP),  they  can  be  hosted  by  any 
number  of  platforms  that  support  X  (e.g.  DEC,  SUN,  Hewlett  Packard).  Additionally, 
their  terminal  characteristics  simplify  systems  administration.  X  as  a  windowing  interface 
currently  cannot  totally  hide  the  specifics  of  die  underlying  operating  system  but  neverthe¬ 
less  facilitates  the  use  of  systems  in  a  multivendor  environment.  A  more  important  issue 
for  systems  integration  will  be  die  file  system,  a  critical  part  of  AIMS  that  has  bridged 
almost  all  functional  components  through  incorporation  of  LAVC  software.  Distributed  file 
systems  are  well  developed  for  homogeneous  networks  like  LAVC  and  SUN'S  Networked 
File  System  (NFS)  but  solutions  for  heterogeneous  networks  do  not  have  die  benefit  of  a 
standard  that  could  be  adopted  by  venders.  AIMS  may  have  to  depend  on  third-party 
solutions  to  maintain  a  possibly  degraded  distributed  file  system. 

6 .  Summary 

In  1986  an  interactive  computer  system  known  as  AIMS  was  developed  by  the 
Satellite  Meteorology  Branch  at  the  then  Air  Force  Geophysics  Laboratory  (now  the 
Geophysics  Directorate  of  the  Phillips  Laboratory)  to  replace  an  aging  and  overburdened 


Me  ID  AS.  The  requirements  for  the  system  specified  a  network  of  distributed  processors, 
each  functionally  unique  and  linked  by  a  local  area  network.  The  emphasis  on  providing  a 
flexible  and  extensible  system  for  research  users  has  been  maintained  throughout  the 
lifetime  of  the  system,  hugely  because  many  of  the  research  users  were  responsible  for  the 
selection,  acquisition  and  development  of  new  hardware  and  software.  Because  AIMS  was 
designed  specifically  as  a  research  tod  for  scientists,  a  decision  was  made  to  select  a 
hardware  and  software  architecture  for  the  system  that  favored  simplicity  of  operation  and 
easy  expansion  over  one  that  emphasized  brute  calculating  power.  Thus  the  VAX/VMS 
architecture  from  Digital  Equipment  Corporation  was  chosen  for  the  processing 
environment  and  the  DECnet  networking  protocol,  later  supplemented  by  the  Local  Area 
VAX  Cluster  protocol,  for  network  communications.  In  spite  of  the  overall  success  of  the 
DEC  configuration,  certain  specific  operations  were  not  easily  implemented  in  this 
environment.  Consequently,  two  special  purpose  computers  were  also  integrated  into 
AIMS;  they  include  a  Gould  (now  Encore)  minicomputer  along  with  necessary  receiver,  bit 
and  frame  synchronizer  hardware  to  handle  real-time  ingest  of  GOES  satellite  data,  three 
Adage  imaging  subsystems  far  image  processing  and  display  operations  and  most  recently 
two  SUN  Sparc  stations  wife  satellite  receiving  antenna  subsystems  for  real-time 
acquisition  of  NOAAATROS  and  DMSP  polar  orbiting  data. 

AIMS  in  its  current  configuration  satisfies  the  needs  of  some  thirty  active  users 
through  four  functional  capabilities:  network  access,  real-time  and  archived  data  sources, 
data  visualization  and  image  processing,  and  interactive  and  batch  processing.  Ethernet 
hardware  provides  the  network  backbone  for  AIMS,  all  systems  are  either  tied  directly  to 
the  AIMS  Ethernet  or  are  reachable  through  a  network  gateway  computer.  Imaging 
systems  are  hosted  on  dedicated  VAXstations  that  are  members  of  the  cluster.  LA  VC 
software  provides  transparent  file  access  among  all  DEC  systems  on  the  network.  The  GP 
broad  band  network  links  fee  AIMS  LAVC  to  numerous  outside  networks  via  an  Ethernet 
bridge.  Outside  networks  including  NSL  DDN,  and  NEARnct  (DDN  and  NEARnet  are 
both  members  of  Internet)  provide  access  to  laboratories,  government  facilities,  and  private 
companies  worldwide.  AIMS  also  has  access  to  a  direct  T1  satellite  link  between  die  Geo¬ 
physics  Directorate  at  Han  scorn  AFB  and  a  Cray-2  supercomputer  at  Rutland  AFB,  NM. 

Meteorological  and  supporting  data  flow  into  AIMS  through  several  possible 
routes:  1)  real-time  direct  broadcast  satellite  transmissions,  2)  network  file  transfers  (e.g., 
FTP),  3)  direct  serial  links,  4)  9  track,  8  mm,  or  4  mm  DAT  magnetic  tape,  or  5)  CD  ROM 
optical  disks.  Satellite  transmissions  are  received  directly  at  one  of  time  satellite  pound 


stations  configured  to  receive  GOES,  HRPT  and  DMSP  broadcasts.  These  subsystems  are 
based  sound  non-ISC  computers  and  require  third-party  software  to  communicate  with 
the  AIMS  LA  VC.  Most  network  file  transfers  from  outside  the  laboratory  enter  the  system 
via  a  separate  gateway  computer  maintained  by  the  Geophysics  Directorate's  main 
computing  center.  This  gateway  computer  is  a  node  on  the  GP  broadband  network  and 
communicates  with  AIMS  using  DECnet  protocols.  The  gateway  computer  is  needed  to 
translate  incoming  data  packets  from  the  Internet  standard  TCP/IP  protocol  to  DECnet  since 
AIMS  currently  does  not  support  TCP/IP.  Plans  to  install  TCP/IP  software  on  AIMS  are 
forthcoming.  At  present,  the  only  data  coming  into  AIMS  through  serial  links  are  lightning 
data  received  indirectly  from  the  S  UN Y- Albany  lightning  detection  network.  The  existing 
connection  to  the  FAA  WB604  line  for  reception  of  conventional  meteorological  data  was 
recently  upgraded  to  the  NWS  Family  of  Services  received  from  a  communications  satellite 
through  a  preexisting  receiving  system.  Data  on  magnetic  tape  are  received  from  numerous 
outside  agencies  including  AFGWC,  ETAC,  NOAA/NESDIS,  NASA,  NCAR,  ASL  and 
GMGO.  Historically,  tapes  have  been  the  preferred  method  for  transferring  data  from 
outside  the  organization;  however,  this  is  rapidly  being  replaced  by  direct  file  transfers  via 
Internet  Recently  the  Defense  Mapping  Agency  began  distributing  large  volume 
geographic  data  sets  on  CD  ROM.  CD  ROM  is  also  becoming  the  preferred  medium  far 
software  vendors  to  distribute  new  and  revised  software  packages  to  customers. 

Visualization  of  data  and  experiment  results  is  probably  the  single  most  important 
capability  on  AIMS.  Virtually  every  scientific  project  that  uses  AIMS  exploits  this 
capability,  at  least  for  quality  control  of  the  input  data  and  validation  of  algorithm  results. 
There  are  basically  two  types  of  display  systems  on  AIMS.  The  first  are  image  processing 
workstations  that  consist  of  VAX  station  3600  single  user  systems  finked  to  Adage  3000 
imaging  subsystems.  Each  workstation  configuration  consists  of  two  monitors;  one  each 
for  fee  VAX  station  and  the  Adage;  large  frame  buffers;  high  speed  bit- slice  processors  for 
processing  raster  data;  multiple  8-bit  look  up  tables;  and  keyboard  and  moose  far  user 
input.  These  systems  are  capable  of  performing  standard  image  processing  and  display 
functions  on  large  multispectral  data  sets  at  interactive  speeds.  The  VAX  station  and  Adage 
subsystems  complement  each  other  functionally  with  the  VAX  station  providing  network 
communications,  a  standardized  user  interface,  and  high  level  graphical  display  capabilities 
while  the  Adage  provides  high  speed  display  and  image  manipulation  functions.  The 
second  type  of  display  system  available  on  AIMS  are  stand-alone  stogie-user  VAX  work¬ 
stations .  These  systems  are  characterized  by  8-bit  color  graphics,  ample  system  memory, 
local  storage  disks,  and  membership  on  the  AIMS  LA  VC  They  provide  an  X  window 
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Used  interface  to  AIMS,  generally  reside  within  individual  offices  and  are  used  for  a 
variety  of  applications  including  software  development,  analysis  and  display  of  meteoro¬ 
logical  data,  wtnd  processing,  network  communications,  and  other  general  purpose 
computing.  X  windows  is  becoming  the  de  facto  interface  standard  for  all  AIMS  work¬ 
stations  due  to  its  functionality  and  nearly  universal  acceptance  across  hardware  platforms. 

Although  AIMS  was  primarily  developed  to  support  interactive  computing  there  has 
been  a  consistent  secondary  need  to  support  relatively  compute-intensive  jobs  through 
batch  processing.  All  VMS  systems  have  batch  queues  as  an  integral  part  of  die  operating 
system,  however,  on  AIMS  a  select  number  of  systems  have  been  tailored  to  handle 
relatively  large  batch  type  operations.  To  satisfy  the  requirement  for  batch  capabilities  in  an 
efficient  manner,  several  system-wide  batch  queues  have  been  developed.  Each  queue  is 
matched  to  a  particular  type  of  application  depending  on  the  requirements  for  memory, 
mass  storage,  CPU,  and  wall  clock  time.  Each  queue  is  backed  by  system  resources 
designed  to  provide  optimal  performance  for  its  particular  type  of  application  with  minimal 
impact  on  the  rest  of  the  cluster.  Also,  in  addition  to  the  capabilities  on  AIMS,  users  have 
direct  access  to  a  VAX  9000  mini  super  computer  and  a  Convex  mainframe  maintained  at 
the  GP  main  computing  center. 

Over  the  six  plus  years  since  its  inception,  AIMS  has  grown  steadily  through  an 
evolutionary  process.  When  shared  access  to  distributed  mass  storage  and  processing  units 
beer  me  possible  through  incorporation  of  LA  VC  software,  AIMS  enhanced  its  networking 
base  to  include  clustering  in  addition  to  DECnet.  Similarly  in  the  late  1980s  a  new 
generation  of  VAX  systems  baaed  on  microprocessor  technology  brought  about  a  quantum 
increase  in  processing  power  over  previously  available  minicomputers.  At  the  same  time 
the  sire,  complexity,  and  cost  of  these  systems  were  reduced  to  a  level  where  small 
organizations  such  as  GPAS  could  now  realistically  afford  to  build  large,  high  powered 
distributed  systems  through  incremental  growth.  Later,  the  idea  of  low  cost,  fast 
microprocessor-based  systems  was  extended  to  t!,e  workstation.  Once  again,  because  of 
its  distributed  nature,  AIMS  was  able  to  expicrt  th is  development  to  put  not  only  here-to- 
fore  unavailable  processing  power  on  a  scientist's  desk  but  to  also  provide  graphics  and 
imaging  capabilities  as  well.  Thus  the  development  of  the  microprocessor  and  workstation 
resulted  in  a  quantum  increase  in  both  the  power  and  sire  of  AIMS.  Unfortunately  this 
growth  did  not  come  without  a  price.  As  the  system  grew  it  was  accompanied  by  a 
dramatic  increase  in  the  complexity  of  system  management  and  planning.  Originally  AIMS 
was  run  by  a  somewhat  haphazard  coalition  of  scientific  end  users  and  programmers.  This 
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arrangement  was  quickly  replaced  by  a  single  designated  system  manager  and  now  has 
grown  to  two  full  time  administrators  and  a  hardware  technician.  In  general  AIMS  has 
been  sensitive  to  the  changing  short  term  needs  of  its  users  and  its  expansion  into  a  division 
wide  resource  has  reemphasized  long  term  planning  issues.  Recently,  a  coalition  known  as 
the  AIMS  User  Group  (AUG)  was  framed  to  1 )  discuss  user  and  system  requirements 
related  to  growth,  policy  changes  or  software  development,  2)  provide  an  outlet  for  the 
technical  exchange  of  AIMS  related  information  and  presentation  of  applications  of  general 
interest,  3)  provide  system  announcements  such  as  scheduled  downtime  for  Systran 
upgrades,  and  4)  discuss  long  range  plans  for  AIMS. 
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Appendix  A:  AIMS  Conventional  Meteorological  Database  Interface 
Module 


ADB_ACQUIRE 


ADB_Acquirc  is  an  Integer*4  function  used  to  access  the  conventional  meteorological  data 
base. 


Format  Istatus  =  ADB_Acquirc(Source,  Key_List,  Data_List) 


Returns  Status  return  values  are  listed  under  Condition  Values  Returned. 


Arguments: 

Source  is  a  Character*12  that  specifies  the  data  source  of  interest  Currently  supported 
sources  include: 


Data  Scum  Source  Specifier 


LFM  Guidance 
LFMMOS 
LFM  Trajectory 
NGM  Guidance 
Service  A 
Synoptic 
Ships  and  Buoys 
METAR 
Upper  Air 
Station  Information 
Radar 


GUIDANCE 

MOS 

TRAJECTORY 

NGM_GUIDANCE 

SERVICE.A 

SYNOPTIC 

SHIPS.BUOYS 

METAR 

UPPER,  AIR 

SID 

MDR 


Key  List  is  a  structure  defined  in  AIMS_Includes:ADBDef.For  with  the  structure  name 
ADB_Key_List.  KeyList  is  used  to  define  how  the  data  is  to  be  retrieved  based  on  time 
and  geographic  location  or  based  on  a  time  series  data  for  a  single  station.  The  elements  of 
this  structure  are  described  below. 


Time  is  an  Integer*4  that  specifies  the  time  for  which  data  is  requested.  Fra*  a 
time  series  request  Time  is  the  start  time  of  the  series.  Time  is  expressed  in  the 
form  YYJJJHHMM. 


Access  Value  is  a  multiply  mapped  element  composed  of  several  different  data 
types.  It  specifies  the  geographic  location,  either  a  point  or  area,  for  which  data  are 
requested.  Only  one  mapped  element  can  be  chosen  for  a  single  invocation  of 
ADB_Acquire.  The  data  types  and  their  definitions  are  listed  below. 

Station  ID  is  a  Character*4  that  specifies  a  single  station  using  a  three 
or  four  letter  station  identifier. 
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StatfcM_No  is  a  Character  that  specifies  a  single  station  wag  a 
station  number. 

State  is  a  Character*  2  that  specifies  all  stations  within  a  state  or 
province. 

Country  is  a  Character*2  that  specifies  all  stations  within  a  country. 

Access  C  is  a  Character *8  that  specifies  all  stations  within  predefined 
latitude~longitude  bounds  (e.g..  New  England). 

NjLat,  S_Lat,  E  Lon,  and  W  Lon  are  Integer*2's  that  specify  the 
north  latitude,  soutK  latitude,  east  longitude  and  west  longitude  of  a 
latitude-longitude  box.  Units  are  degrees*  100.  Latitudes  rangefrom  9000 
to  -9000,  positive  north.  Longitudes  range  from  18000  to  -18000,  positive 
east 

SIDFlags  is  an  Integer*2  used  a  bit  mask  to  control  aspects  of  the  collection  of 
station  information  for  the  data  request.  Bits  0  through  3  are  used  to  inform  die 
station  data  base  utility  SID_Acquire  how  to  organize  the  collection  of  stations.  The 
modifiers  used  for  these  bits  include: 


Station  identifier  SID _ ID 

Station  number  SID _ Number 

State  SID _ State 

Country  SID__Country 

Lat-Lon  Box  SID_LatLon 

The  next  bit,  bit  4,  is  known  as  the  "ADB  only”  bit  This  bit  is  used  to  inform 
SED_Acquirc  to  use  a  type  specific  station  data  base  file  to  retrieve  station 
information  rather  than  the  master  station  data  base  file,  thereby  reducing  I/O 
overhead.  If  SID_ Acquire  determines  dial  a  type  specific  station  data  bare  file  does 
not  exist,  it  will  use  the  master  file.  The  modifier  that  activates  this  bit  is 
SID _ ADB_Only. 

Bits  5  through  IS  are  used  to  inform  SID_ Acquire  the  type  of  station(s)  for  which 
information  is  being  retrieved.  The  modifiers  used  far  these  bits  include: 

SID _ Synoptic 

SID _ MOS 

SID _ Guidance 

SID__Trajectory 

SID _ RAOB 

SID _ Radar 

SID _ METAR 

SID _ Service_A 

SID _ NGM_Guidance 

Timelnterval  is  an  unsigned  Byte  that  specifies  the  length  of  the  time  interval 
for  a  done  series  request.  Values  range  from  1  to  255  hours. 
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Timelncrement  is  a  Byte  that  specifies  a  time  increment  for  a  time  series 
request.  Values  range  from  1  to  63.  Units  are  specified  by  the  use  of  a 
modifier.  They  include: 

ADB_M_Seconds 

ADB_M_Minutes 

ADB_M_Hours 

ADB_M_Days 

Reserved  is  an  Integer*4  reserved  for  future  use. 

Data_List  is  an  item  list  defined  by  the  structure  in  AIMS_Includes:ADBDef.For  with  the 
structure  name  ADBJDataJList.  The  elements  of  this  structure  are  defined  as  follows: 

Data_Type  is  an  Integer*4  that  specifies  the  data  type  of  interest  Data  types  are 
source  dependent,  refer  to  the  attached  table  that  lists  valid  data  types  for  all 
supported  data  sources.  The  following  is  a  list  of  symbolic  constants  to  use  to 
specify  Data  Type. 

ADB _ Temperature 

ADB _ Dewpoint 

ADB _ Pressure 

ADB _ R1 

ADB _ R2 

ADB _ R3 

ADB _ VerticaLVelocity 

ADB _ Stability 

ADB _ Wind_  Direction 

ADB _ Wind_Speed 

ADB _ PrccipJ3 

ADB _ Precip_6 

ADB _ Precip_12 

ADB _ Precipj24 

ADB _ POP06 

ADB _ POP  12 

ADB„QPF06 

ADB_QPF12 

ADB  TStorm  Prob 

ADB_Min_Temperature 

ADB__Max_Temperature 

ADB _ Cloud_Am  t_Prob 

ADB_Ceiling_Hgt_Prob 

ADB _ Visibility_Prob 

ADB _ Bcst_C_V 

ADB _ Obstruction_Prob 

ADB_Geopotential_Height 

ADB _ Altimeter 

ADB _ Station_Pressure 

ADB _ jPrcssure_Tendency 

ADB_Qoud_Amt_Oktas 

ADB _ Cloud_Amt 

ADB_Total_Cloud  Amt 

ADB _ Goud_Type 

ADB _ Goud_Height 
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ADB _ Gust 

ADB _ Snow.Depth 

ADB _ Snow_Accuntuladon 

ADB _ Frcezing_Level 

ADB_Wave_Feriod 

ADB_Wave_Hcight 

ADB _ StationID 

ADB _ Station_Numbcr 

ADB _ Station_Lat 

ADB _ Station_Lon 

ADB _ Station_Height 

ADB _ StadonLocation 

ADB _ I 

ADB _ J 

ADB _ Thickness 

ADB_Mixing_Ratio 

ADB _ Spccific_Humidity 

ADB _ RH 

ADB _ Potcntial_Temp 

ADB _ VirtualTemp 

ADB _ V  apor_Pressure 

ADB _ Sat_Vapor_Pressure 

ADB _ Eq_Temperature 

ADB_Wct_Bulb 

ADB _ LCL 

ADB _ Lifited_Index 

ADB_Eq_Potential_Temp 

ADB _ latitude 

ADB _ Longitude 

ADB _ MDR_Grid 

ADB _ Cell_Top 

ADB _ Cell_Direcdon 

ADB _ Cell_Speed 

ADB _ Sea_SFC_Temp 

ADB _ DDFF 

ADB_DDFFF 

ADB _ Wind_Flags 

ADB _ Wind_  Vectors 

ADB _ Streamlines 

ADB _ Day 

ADB _ Hour 

ADB _ ParceLTrajectory 

ADB_Wind_aill_Temp 

ADB _ Signal_Strength 

ADB _ Multiplicity 

ADB _ Seconds 

ADB _ T1 

ADB _ T3 

ADB _ T5 

ADB _ Structure* 

*  The  data  type  ADB  __Slmcturc  is  used  to  retrieve  the  raw  record(s)  from  a  particoiar 
dma  source.  No  formatting  or  unit  conversion  is  performed. 


There  are  also  numerous  modifiers  associated  with  Data  Type  that  are  valid  for 
certain  d«*a  sourcc/type  combinations.  The  use  and  meaning  of  these  modifiers  is 
described  below.  Note  -  parameters  are  combined  with  one  or  more  modifiers 
through  logical  'or’ing. 

For  METAR  and  Synoptic  data  there  are  modifiers  to  limit  the  retrieval  of 
cloud  information  to  certain  layers  or  to  gather  data  from  all  layers: 

ADB_M_Layer_l 

ADB_M_Layer_2 

ADB_M_Layer_3 

ADB_M_Layer_4 

ADB_M_All_Layers 

For  Upper  Air  data  there  are  modifiers  to  specify  data  for  a  particular  mandatory 
level: 


ADB_M_Surface 

ADB_M_1000mb 

ADB_M_850mb 

ADB_M  700mb 

ADB_M_500mb 

ADB_M_400mb 

ADB_M_300mb 

ADB_M_250mb 

ADB_M_200mb 

ADB_MJ50mb 

ADB_M_100mb 


and  the  tropopause  level  and  level  of  maximum  winds: 

ADB_M_Tropopause 

ADB_M_Max_Winds 

as  well  as  a  sorted  retrieval  of  mandatory  and  significant  level  pressure  data: 
ADB_M_All_Sorted 


When  used  in  conjunction  with  ADB _ Structure,  the  following  modifiers  define  die 

type  of  raw  data  to  retrieve. 


ADB  _M_TTAA 
ADB_M_TTBB 
ADB_M_PPBB 
ADB.M  Hourly 


Mandatory  level  temperature  data 
Significant  level  temperature  data 
Significant  level  wind  data 
Service  A  hourly  data 


ADB_M_Remarks  Service  A  remarks 
ADB_M.MDR_Grid  MDRgrid 
ADB_M_MDR_Cells  MDR  cell  information 


Data  Buffer  Adr  is  an  Integer*4  that  specifies  the  starting  address  c"  a  buffer 
that  will  be  used  to  receive  the  data. 
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DaU_Buffer_Len  is  an  Integer*4  that  specifies  the  size  of  the  buffer  in  bytes. 

Data  Format  is  a  Byte  that  specifies  the  output  format  of  the  data.  Modifiers  are 
used  to  indicate  the  format. 

ADB_M_Integer  for  integer  format 

ADB_M_Rcal  for  floating  point  format 

ADB_M_Character*  for  character  format  (63-character  maximum) 

*  For  character  format,  the  receive  buffer  character  string  length  must  be  logically  or’ed  with 
the 

parameter. 

Example:  Character* 4  Station_ID(10) 

Data_List(l).Data_Format  =  ADB_M_Character  .or.  4 

Valid  Time  is  a  Byte  that  specifies  a  forecast  va^d  time  when  used  with  LFM  or 
NGM  guidance,  MOS,  or  trajectory  data  sources. 

Missing  data: 


Missing  data  is  flagged  with  parameters  based  on  data  format: 


Parameter 


Format  Value 


ADB_Missing_I 

ADB_Missing_R 

ADB_Missing_C 


integer  2^ 

teal  2M  (16777216.0) 

character  77  (the  letter  M) 


For  entire  reports  missing  (with  the  use  of  ADB _ Structure): 


ADB_Missing_Report_I  integer 

ADB_Missing_Report_R  real 
ADB_Missing_Report_C  character 


Description: 


225 

225  (33554432.0) 
42  (asterisk) 


ADB  Acquire  is  a  single  point-of-acccss  programming  interface  to  the  conventional 
meteorological  data  base.  For  a  specified  data  source,  ADB_Acquire  can  retrieve  one  or 
more  data  types  for  a  point  source  (i.e.,  station)  or  a  geographic  area  (e.g.,  state,  latitude- 
longitude  box).  For  a  time  series  request,  the  function  will  retrieve  one  or  more  data  types 
for  a  single  station  over  the  time  period  defined  by  the  series.  There  are  no  artificial 
restrictions  placed  on  the  number  of  data  types  that  can  be  retrieved  per  invocation.  This  is 
because  ADB_ Acquire  makes  use  of  the  VMS  item  list  to  string  together  data  type  requests. 
The  physical  limitation  is  governed  by  the  number  of  valid  data  types  that  exist  for  a 
particular  data  source.  ADB_Acquire  makes  use  of  the  VAX/VMS  item  list.  Programmers 
unfamiliar  with  the  item  list  should  reference  the  appropriate  VMS  documentation 
beforehand.  Also  the  programmer  is  expected  to  know  approximately  how  much  data  will 
be  returned  for  any  given  call,  allocating  a  buffer  or  buffers  large  enough  to  accommodate 
the  request. 

An  interactive  implementation  of  ADB_Acquire  is  available  through  the  AIMS  DCL 
command  ADB  (see  the  AIMS  applications  documentation  or  on-line  Help  for  the  use  of 
ADB). 
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Example  Code  Stub: 


Program  ADB_Example 

ADB  includes  needed  for  constructing  the  key  and  data  lists 

Include  ‘AIMS_Includes:ADBDef.For' 

Include  ’AIMSJncludestSIDDef.For’ 

Record  /ADB_Key_List/  Key_List 
Record  /ADB_Data_Ust/  Data_List(3) 

Character*  1 2  Source  /SER VICE_A  7 
Integer*4  ADB_Acquirc,  N_Points,  Iret 
Real*4  Temp(lOO) 

Character*4  Station_ID{100) 


Application  - specific  code 


Begin  ADB  call  setup 

Access  is  by  state,  using  Service  A  stations  only. 

The  SID  parameters  (SID _ ...)  arc  defined  in  SIDDef.For 

Kcy_List.State  =  'CA'  !  California 

KeyJList.Ski_Flags  =  SID _ State  .or.  SED_Service_A  .or.  SID_ADB_Only 

Time  is  given  in  YYJJJHHMM 

KeyJList.Time  -  892790000  !  6-Oct-1989, 0Z 

The  item  list  entry  for  temperature.  Note  that  %loc()  returns  the  address  of  a  variable. 

The  buffer  length  is  always  given  in  bytes.  Parameters  ADB _ ...  or  ADB_M_...  arc 

defined  in  ADBDef.For 

Data_List(  1  ).Data_Type  =  ADB _ Temperature 

Data_List(l).Data_Buffer_Adr  =  %loc(Temp) 

Data_List(l).Data_Buffer_Len  =  400 
DataJList(l).Data_Format  =  ADB_M_Real 

The  item  list  entry  for  station  ids 

Data_List(2).Data_Type  =  ADB _ Station_ID 

Data_List(2).Data_Buffer_Adr  =  %loc(Station_ID) 

Data_List(2).Data_Buffer_Len  =  400 
Data_List(2).Data_Format  =  ADB_M_Character  .or.  4 

The  item  list  terminator.  Parameter  ADB _ End  is  0 

Data_List(3)Data_Type  =  ADB _ End 

Call  the  data  base  interface 
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bet  *  ADB_Acquire(  Source,  Key_List,  DataJList) 
C 


C  Determine  the  number  of  data  points  found 
C 

N_Points  *  (400  -  Data_List(l).Data_Buffer_Leo) /4 
C 


C  Continue  application 
C 


Condition  Values  Returned: 

ADB_Nonnsl  ~  Normal  completion  status  value. 

ADB_Buffer_Full  ~  The  user  supplied  buffer  was  filled  before  data  collection  had 
completed.  Increase  the  size  of  the  buffer  and  try  again. 

ADB_Invalid„Format  --  An  invalid  data  format  was  specified. 

ADB__Wegal_Access  -  A  time  series  request  was  made  for  geographic  access  other  than  a 
single  station. 

ADB_Illegal_Tune_Units  -  The  units  of  the  time  interval  for  a  time  series  request  was 
invalid. 

ADB_Illegal_Tune_Incrcment  -  An  invalid  time  increment  was  specified  (Value  was 
outside  of  range  1  to  63). 

ADBJJnkSource  -  An  unknown  data  source  was  specified. 

ADB_NonJExistent_Recofd  -  No  data  for  the  time  and  location  specified  was  avails  We. 

ADBJRead JError  -  This  is  an  I/O  error  produced  by  FORTRAN  for  a  status  return  that  is 
something  other  than  ADB_Non_Existent_Record.  Notify  the  AIMS  System  Manager. 

ADB_Open_Failure  «  This  is  an  I/O  error  produced  by  a  non-zero  status  return  from 
FORTRAN  OPEN.  Notify  the  AIMS  System  Manager. 

ADB_Missing_Data  -  Some  or  all  of  the  requested  data  is  missing. 

ADB  JBuffer_Too_Small  -  The  specified  user  buffer  was  too  small  for  the  data  record. 
Valid  for  data  type  ADB _ Structure  only. 

ADB_Invalid_Data_Type  -  The  data  type  specified  is  not  valid  for  the  requested  data 
source. 

ADB_lnvaikLValid_Time  -  The  forecast  verification  time  specified  is  not  valid  for  the 
requested  data  source. 

ADB  Jnvalid_Data_Modifier  -  The  data  type  modifier  specified  is  not  valid  for  die  data 
source  and  type  requested. 
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ADB_NonJExistent_Houriy  -  Same  as  ADB_Non_Existent_Record  but  for  surface 
hourbes  only  (i.c.,  Service  A,  Synoptic  and  ShijVBuoy  data  sources). 

ADB_Non_Existent_  Remarks  -  Same  as  ADB_Non_Exi«ent_Hourly  but  for  surface 
hourly  remarks. 

ADBJJnkAccess  --  An  unknown  access  type  was  specified  in  the  key  list 

ADB.UnkModifrer  -  An  unknown  data  type  modifier  was  specified. 

APB  String  Too  Long  -  Tire  user  specified  character  string  was  too  small  to  contain  the 
data  when  converted  to  character  format  Increase  the  size  of  the  string  and  try  again. 


Appendix  B: 

AIMS  Conventional  Meteorological  Station  Database  Interface 

Module 

SID_ACQUIRE 

SID.Aoquire  is  an  Integer*4  function  used  to  access  the  conventional  meteorological 
station  data  base,  returning  full  station  information  on  an  individual  station  or  group  of 
stations. 

Format 

Is  tarns  =  SID_Acquire(SID,  Flags,  Index) 

Returns 

Status  return  values  are  listed  under  Condition  Values  Returned. 

Arguments: 

SID  is  a  record  of  the  structure  GLOBAL_STN  which  is  defined  in  the  SID  include  file 
AIMS_Includes:SIDDcf.For.  It  consists  of  the  following  elements: 

Character’d  ID,  a  three  or  four  letter  station  identifier  (e.g.,  BOS  for 
Boston/Logan) 

Character*6  Num,  a  6-digit  code  number  for  a  station  (e.g.,  72509  for  Boston). 
Note  that  character  position  6  is  frequently  a  space. 

Integer*2  Lat,  the  latitude  of  the  station  in  degrees*  100.  Latitudes  range  from 
9000  to  -9000,  positive  north. 

Integer*2  Lon,  the  longitude  of  the  station  in  degrees*  100.  Longitudes  range 
from  18000  to  -18000,  positive  west. 

Character*2  State,  the  state  or  province  of  the  station. 

Character*2  Cntry,  the  country  of  the  station. 

Integer*2  Hgt,  the  elevation  of  the  station  in  meters. 

Character*19  Loc,  a  text  description  of  the  station  location. 

Byte  Class,  a  bit  mask  used  to  represent  the  types  of  reports  that  a  station  is 
normally  expected  to  report.  Each  bit  is  representative  of  whether  a  station  reports 
any  of  8  different  types  of  reports.  Class  is  defined  by  the  logical  ’or'ing  of  the 
types  of  reports  a  station  is  known  to  produce.  Bits  one  to  eight  indicate 
respectively  that  a  station  produces  Service  A,  METAR,  Radar,  Upper  Air, 
Trajectory,  Guidance,  MOS,  or  Synoptic  reports. 

Flags  is  an  Integer*2  which  indicates  how  the  station  data  base  is  to  be  accessed,  the 
type  of  stations  of  interest,  and  whether  all  stations  of  the  specified  type  are  to  be  returned 
or  if  only  those  stations  present  in  the  AIMS  conventional  database  are  to  be  returned. 


53 


Flag  access  designation  parameters:* 

SID _ Number  -  Stations  are  to  be  accessed  by  passing  one  station  number  in  each 

element  of  the  declared  SED  station  data  structure. 

SED_NumList  -  Stations  are  to  be  accessed  by  passing  a  partial  station  number 
in  the  first  element  of  the  declared  SID  station  data  structure.  All  stations  with 
station  numbers  matching  die  passed  portion  of  the  number  will  be  returned. 

SID _ ID  --  Stations  are  to  be  accessed  by  passing  one  station  id  in  each  element  of 

die  declared  SID  station  data  structure. 

SID_LatLon  --  Stations  are  to  be  accessed  by  passing  the  latitude  and  longitude  of 
the  northwest  and  southeast  comers  of  a  box  in  records  one  and  two  of  the  user 
declared  SID  station  data  structure. 

SID_Country  -  Stations  are  to  be  accessed  by  country  which  is  defined  in  the 
'Cntry'  element  of  the  first  entry  of  the  SID  station  data  structure. 

SID _ State  -  Stations  are  to  be  accessed  by  state  which  is  defined  in  the  'State' 

dement  of  the  first  entry  of  the  SID  station  data  structure. 

SED _ Continue  -  A  flag  modifier  that  indicates  when  the  initial  array  is  too  small  to 

continue  the  previously  requested  group  of  stations  at  the  point  terminated  on  the 
previous  call.  Do  not  set  any  other  flag  modifiers  on  any  number  of  subsequent 
calls. 

Flag  station-type  modifying  parameters: 

SID _ Synoptic  --  Only  stations  that  broadcast  synoptic  reports  will  be  returned. 

SID _ MOS  —  Only  stations  that  broadcast  MOS  reports  will  be  returned. 

SED _ Guidance  -  Only  stations  that  broadcast  LFM/NGM  Guidance  reports  will 

be  returned. 

SED _ Trajectory  -  Only  stations  that  broadcast  MOS  trajectory  reports  will  be 

returned. 

SID _ RAOB  -  Only  stations  that  broadcast  Raob  or  upper  air  reports  will  be 

returned. 

SID _ Radar  -  Only  stations  that  broadcast  Radar  reports  will  be  returned. 

SID _ METAR  -  Only  stations  that  broadcast  METAR  reports  will  be  returned. 

SID _ Service_A  --  Only  stations  that  broadcast  Service  A  reports  will  be  returned. 

*  -  By  convention  parameters  are  indicated  by  tire  utility  id  followed  by  two 

underscores,  in  this  case  SID _ .  Functions  and  return  codes  are  indicated  by  tire 

utility  id  followed  by  a  single  underscore. 
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SID _ ADB_Only  ~  A  modifier  indicating  the  only  stations  of  the  requested  type 

actually  in  the  AMS  conventional  data  base  that  should  be  returned 


Index  is  an  Integer4  2  which  in  being  passed  indicates  how  many  structures  for  the 
station  information  have  been  declared  and  in  returning  indicates  how  many  of 
those  structures  were  filled 

Description: 

Hie  ability  to  acquire  station  information  and  in  particular,  the  latitude  and  longitude  of 
stations  within  given  geographical  bounds,  is  an  important  part  of  the  ability  to  access  the 
AIMS  conventional  meteorological  data  base.  S1D_ Acquire  is  the  standard  programming 
interface  to  access  the  global  station  database.  An  interactive  implementation  of 
SID_Acquire  is  available  through  the  AIMS  DCL  command  SID  (see  the  AIMS 
applications  documentation  or  on-line  Help  for  the  use  of  SID). 

Two  examples  of  use: 

1)  To  retrieve  a  single  station: 

Program  GET_Sid 

Include  'AIMS_Jncludes:SIDDef.For' 

Integer*2  Index,  Sid_Flags 
Record  /Global  JStn/  Sid 


Sidld  =  BOS  ’ 

Flags  =  SID _ ID 

Index  =  1 

Iret  =  SID_Acquire(SID,  Rags,  Index) 


Sid  Structure  Returns: 

Sidld  «  BOS  ’ 

SidNumber  =  725090' 

SidHgt  =  9 

SidLoc  =  ’BOSTON/LOGAN  INTL  &’ 

Sid.Lat  =  4236 

Sid.Lon  =  7103 

Sid.  Class  =  ’Fl’X 

SidState  =  ’MA’ 

SidCntry  =  ’US' 


Index  returns  a  value  of  1. 

Iret  returns  a  value  of  l  (normal). 

2)  To  retrieve  all  Service  A  stations  within  given  geographical  bounds: 
Program  GET  Sid 

Include  AIMS  JncludesiSIDDef-For' 
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Integer*!  Index,  Sid_FUgs 
Record  /GiobaLStn/  Sid(20) 


Sid(l).Lat  =  4000 
Sid(l)Xon  *  10000 
Sid(2).Lat  =  3500 
Sid(2)lyOn  =  9500 

Flags  »  SID _ ID  .or.  SID _ Service_A  .or.  SID _ ADB_Only 

Index  -  20 

bet  *  SED_Acquire(SID,  Flags,  Index) 

Sid  Structure  Returns: 

Sid(l).Id  =  HBR  ’  IHobart,  Oklahoma 
to 

Sid(20).Id  =  RSL  '  !  Russell,  Kansas 

Index  is  20,  indicating  that  all  the  station  structures  were  filled. 

bet  is  equal  to  SID _ LimExced  indicating  that  there  are  more  stations  in  the 

given  bounds  to  be  retrieved.  SID_Acquire  is  subsequently  called  again: 

Flags  =  SID _ Continue 

Index  =  20 

bet  =  SID_Acquire(SID,  Flags,  Index) 


Sid  Structure  Returns: 

Sid(l).Id  =  ’FOE '  ITopeka/Forbcs  Kansas 
to 

Sid(6).Id  =  'CNK '  IConcordia/Blosser  Kansas 
Index  *  6 

bet  =  1,  indicating  a  normal  completion  of  the  acquisition 

Condition  Values  Returned: 

SIDJLimciT  -  A  zero  or  negative  value  for  Index  was  passed  to  the  routine. 

SID.niOpt  -  An  illegal  value  of  Flags  was  passed  to  the  routine  (most  likely  more  than 
one  mode  of  access  was  specified). 

SEDJLatOrd  -  The  latitudes  in  a  lat/km  search  were  passed  out  of  order. 

SID_LonOtd  -  The  longitudes  in  a  lat/lon  search  were  passed  out  of  order. 
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SED_OpnFail  —  TTie  routine  could  not  open  die  data  files.  Notify  the  system  manager, 

SID.KeyNotFnd  —  No  records  satisfying  the  request  could  be  found. 

SID_LiniExced  --  There  are  more  stations  satisfying  the  request  than  records  available  to 
place  them.  The  routine  may  be  recalled  with  Flags  set  to  SID_Continue  which  will  pick 
up  where  the  former  call  ended. 


Appendix  C:  AIMS  Projection  Transform  Module 


AMLJTRANSFORM 


AML_Transform  is  an  Integer*4  function  that  converts  a  coordinate  or  array  of  coordinates 
front  one  projection  to  another. 

Formal  Iret  =  AMLJTransform(Proj_In  JProj_OuUC_In,Y_InJC_Out,Y_Out,Count) 

Returns  Status  return  values  are  listed  under  Condition  Values  Returned. 


Arguments: 

Proj  in  is  a  structure  defined  in  AIMS_lncludes:AMLDef.For  with  die  structure  name 
Frcyectkm_Structure.  This  structure  is  composed  of  a  fixed  element  and  multiply-mapped 
element  sets  that  are  projection  specific.  ProjJLn  contains  information  relevent  to  die 
input  or  "from"  projection. 

Fixed  element: 

Projection  is  an  Integer*4  that  indicates  the  projection  type.  Valid  values  are 
defined  in  AIMS_Inc!udes:AMLDef.For  and  include  the  following: 

AML_From_Ladon 
AML  From  Mercator 
AML_From_PSG 
AML__J3romJLambert 
AML _ From_Geostationary 

In  addition.  Projection  is  used  to  specify  bit-wise  modifiers  that  control  certain 
aspects  of  the  transformation  procedure.  These  modifiers  are  defined  in 
AIMS_IncIudcs:AMLDef.For  and  include  the  following: 

AML_Initialize  -  Perform  initialization  prior  to  transformation 
AML_U_Coords  -  Coordinates  are  relative  (IJ) 

Mapped  element  set  #1: 

Lat_l  is  a  Real *4  that  specifies  the  latitude  of  projection.  Valid  for  Mercator, 
polar-stereographic,  and  Lambert-conformal  projections.  For  Lambert-conformal 
Lat_l  is  the  primary  latitude. 

Lat  2  is  a  Real*4  that  specifies  the  secondary  latitude  of  projection.  Vaild  for 
Lambert-conformal  projections  only. 

Long  is  a  Real *4  that  specifies  the  longitude  of  mentation.  Valid  for  Mercator, 
polar-stereographic,  and  Lambert-conformal  projections. 
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GrW_ Width  is  a  Real  *4  that  specifies  die  geometric  spacing  in  kilometers  if 
relative  (IJ)  coordinates  are  used.  Valid  for  Mercator,  polar-stertxjgraphic,  and 
Lambert-conformal  projections. 

I_np  is  a  Real *4  that  specifies  the  column  position  of  the  North  Pole  for  polar- 
stcreographic  and  Lam  ben-conformal  projections  or  the  column  position  or  the 
equator  for  Mercator  projection. 

J_np  is  a  Real*4  that  specifies  the  row  position  of  the  North  Pole  for  polar- 
stereographic  and  Lambert-conformal  projections  or  die  column  position  of  die 
equator  for  Mercator  projection. 

As  an  alternative,  this  element  set  can  be  specified  using  logicals.  Default  values 
exist  in  die  system  logical  name  table  under  die  following  logical  definitions: 

AML_PRJMARY_LAT_FROM 

AML_SECONDARY_LAT_FROM 

AML_LONG_OF_ORIENTAnON_FROM 

AML_GRID_WIDTH_FROM 

AML_I_NP_FROM 

AMLJLNPJFROM 

By  specifying  new  definitions  in  one's  process  logical  name  table,  these  defaults 
can  be  easily  overridden. 

Mapped  element  set  #2: 

SSYYDDD  is  an  Integer*4  that  specifies  the  satellite,  year,  and  julian  date  of 
interest  Valid  for  geostationary  projection. 

HHMMSS  is  an  Integer*4  that  specifies  the  time  of  interest.  Time  is  in  packed 
integer  format.  Valid  for  geostationary  projection. 

Channel  is  an  Integer*4  that  specifies  the  channel  of  interest.  Values  are 
specified  as  holleriths  with  blank  fill.  Valid  values  include: 

Visible  =  ’VIS ' 

Small  detector  IR  =  'SIR '  (1 1  um) 

Large  detector  IR  =  LIR  ’  (3.7, 6.7, 12  um) 

Center  Lat  is  an  Integer*4  that  specifies  the  center  point  latitude  in  degrees  and 
hundredths  x  100.  Valid  for  geostationary  projection. 

Center  JLong  is  an  lnteger*4  that  specifies  the  center  point  longitude  in 
degrces'and  hundredths  x  100.  Valid  for  geostationary  projection. 

Line  Res  is  an  Integer*4  that  specifies  the  satellite  line  resolution  in  kilometers. 
VaikTfcr  geostationary  projection. 

ElementJRes  is  an  Integer*4  that  specifies  the  satellite  element  resolution  in 
kikxneteri.  Valid  for  geostationary  projection. 
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Number  JLines  is  an  Integer*4  that  specifies  the  number  of  satellite  lines. 
Valid  for  geostationary  projection. 

NumberJElements  is  an  Integer*4  that  specifies  the  number  of  satellite 
elements  per  line.  Valid  for  geostationary  projection. 

As  an  alternative  this  element  set  can  be  specified  using  logicals.  Default  values 
exist  in  the  system  logical  name  table  under  the  following  logical  definitions: 

AML_SSYYDDD_FROM  (no  default) 

AML_HHMMSS_FROM  (no  default) 

AML_CHANNEL_FROM 

AML_CENTER_LAT_FROM 

AML_CENTER_LONG_FROM 

AML_UNE_RESOLUTION_FROM 

AML_EUEMENT_RESOLUTION  FROM 

AML_NUMBER_UNES_FROM 

AML_NUMBER_ELEMENTS_FROM 

By  specifying  new  definitions  in  the  process  logical  name  table,  these  defaults  can 
be  easily  overridden. 

Proj_Out  is  also  a  structure  defined  in  AIMS_Includes:AMLDef.For  with  the  structure 
name  Projection_S tructurc.  Proj_Out  contains  information  relevant  to  the  output  or  "to" 
projection  and  is  specified  in  almost  identical  fashion  to  Proj_In.  The  exceptions  are 
projection  type  and  logical  names  which  are  identified  as  follows: 

AML_To_Latlon 

AML_ToMcrcator 

AML__To_PSG 

AML_To_Lambert 

AML_To_Geostationary 

AML_PRIMARY_LAT 

AML_SEOONDARY_LAT 

AML_LONG_QF_ORENTATION 

aml.gridwidth 

AML_I_NP 

AML_J_NP 

AML_SSYYDDD  (no  default) 

AML_HHMMSS  (no  default) 

AML_CHANNEL 

AMLCENTER_LAT 

AML_CENTER  LONG 

AML_UNE_RESOLUTION 

AML_ELEMENT_RESOLUTION 

AML_NUMBER_LINES 

AML_NUMBER_ELEMENTS 

XIn  is  a  Real*4  that  specifies  the  input  (from)  x  coordinate(s). 

Y  in  is  a  Real*4  that  specifies  the  input  (from)  y  coordinate(s). 

X_Out  is  a  Real*4  that  specifies  the  output  (to)  x  coordinate(s). 
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YOut  is  »  Real *4  that  specifics  the  output  (to)  y  coordinate^). 

Icount  is  an  Integer*4  that  specifies  the  number  of  (x,y)  coordinates. 

Description: 

AML.TRAN SPORM  is  a  function  that  converts  a  coordinate  or  array  of  coordinates  from 
one  projection  to  another.  Currently  supported  projections  include  latitude-longitude, 
Mercator,  polar-stenographic.  Lambert-conformal,  and  geostationary  (spin-scan  GOES). 
AMLJTRANSFORM  performs  transformations  using  a  three- step  procedure: 

1)  Initialization 

2)  Convert  input  coordinates  to  latitude, longitude 

3)  Convert  latitude  .longitude  to  output  coordinates 

All  projections  (with  the  exception  of  latitude-longitude)  require  initialization  whether 
specified  on  the  input  or  output  side  of  the  transformation.  This  is  accomplished  by  setting 
the  appropriate  bit  in  the  "projection”  structure  element  and  providing  relevant  initialization 
parameters  either  through  the  projection  structure  or  as  logical  definitions.  If  logicals  are 
used,  corresponding  structure  elements  must  be  set  undefined  using  preset  data  type 
dependent  mask  values  defined  in  the  include  file  (see  example).  Default  logical  definitions 
exist  in  die  system  logical  name  table  and  can  be  overridden  by  specifying  the  logical  names 
in  the  process  logical  name  table.  Note  that  some  logicals  do  not  have  defaults  arid  must 
therefore  be  explicitly  defined  by  the  user  before  program  activation. 

Transformations  from  latitude-longitude  to  any  other  projection  will  preserve  the  contents 
of  X_In,Y_In.  All  other  combinations  replace  the  contents  of  these  two  calling  arguments 
with  intermediate  latitude  Jon gitude  calculations. 

Latitudes  range  from  -90.0  to  +90.0,  north  positive. 

Longitudes  range  from  -180.0  to  +180.0,  east  positive. 

Example  Code  Stub: 

Include  'AEMS_Includes.AMLDef.For/NOLIST 
Record  /Projection__Structurc/  Proj_In,  Proj_Out 


Proj^In.  Projection  =  AML _ Frotn_Latlon 

Proj_Ou  t.  Projection  =  AML__To_PSG  .OR.  AML _ Initialize  .OR.  AML _ U_Coords 


C 

C  Use  defaults  from  the  system  logical  name  table 
C 


Proj_Out.Lat_l  =  AML _ Undefined 

Proj_Out.Lat_2  =  AML__Undefined 

Proj_Out.Lcmg  *  A  ML _ U  ndef ned 

Prqj_OutGrid_Width  *  AML _ Undefined 

Proj  OutI_NP  =  AML _ Undefined 

Proj.Out.J_NP  =  A  ML _ Undefined 
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c 

Xlat  =  90,0 
Xlon  =  -105.0 

fact  *  AML_Transform(Proj_In  J5roj_Out^Xlon^Xlat,XivXj,  1 ) 

Returns: 

Xi  *0.0 
Xj  =  0.0 

fact  =  AML _ Normal 

Condition  Values  Returned: 

Normal  completion  status  code  is  AML_Normai.  Error  return  codes  relate  to  undefined  or 
illegal  values  fen’  passed  structure  elements  or  logical  definitions. 
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Appendix  D:  AIMS  Clock  Modules 


CLKGETTIM 


CLK_Gettim  is  an  Integer*4  function  that  converts  date  and  time  given  in  any  one  of 
several  formats  to  ail  other  formats,  possibly  adjusted  by  a  time  offset 


Format  Iret  =  CLK_Gettim(Function,  Clock,  Time_0ffset) 


Returns  Status  return  values  are  listed  undo*  Condition  Values  Returned. 


Arguments: 

Function  is  an  Integer*4  that  indicates  the  time  format  that  is  being  passed  to 
CLK_Gettim.  The  following  formats  defined  in  AIMS_Includes:CLKDef.For  are  allowed: 

CLK _ Current  requests  the  current  time  passed  into  all  formats.  For  this  format 

request,  no  elements  of  the  clock  structure  need  be  defined. 

CLK _ ASCII  indicates  that  time  is  being  passed  in  VAX  Time  String  Format  in 

the  clock  structure  element  ‘Time’. 

CLK _ NanoS  indicates  that  time  is  being  passed  in  quad  word  format  in  hundreds 

of  nanoseconds  in  the  clock  structure  element  ‘Nanos’. 

CLK _ Julian  indicates  that  time  is  being  passed  in  Julian  date  format 

(YYJJJHHMM)  in  the  clock  structure  element  ‘Julian’. 

CLK _ Integer  indicates  that  time  is  being  passed  as  integer  components  in  the  clock 

structure  elements  ‘Year’,  ‘Month’,  ‘Day’,  ‘Hour’,  ‘Minute’,  ‘Second’,  and 
‘Hundredths’. 

Clock  is  a  structure  defined  in  AIMS_Includes:CLKDef.For  with  the  structure  name 
CLK_Structure.  When  passed.  Clock  contains  one  or  more  elements  that  are  defined 
according  to  the  Function  requirement.  Upon  successful  completion  all  elements  arc 
defined.  These  elements  are  described  below: 

Year  is  an  Integer*2  that  indicates  the  year  in  the  form  I9XX. 

Month  is  an  Integer*2  that  indicates  the  month  in  numeric  form  from  1  to  12. 

Day  is  an  Integer*2  that  indicates  the  day  in  numeric  form  from  1  to  31. 

Hour  in  an  Integer*2  that  indicates  the  hour  in  the  range  0  to  23. 

Minute  is  an  Integer*2  that  indicates  the  minute. 

Second  is  an  Integer*2  that  indicates  the  second. 
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Hundredths  is  an  Integer*2  that  indicates  the  hundredth  of  second. 


DayOfWeek  is  an  Integer*4  that  indicates  the  day  of  the  week  where  Monday  is 
day  1  and  Sunday  is  day  7. 

Julian  is  an  Integer*4  that  indicues  the  Julian  date  in  the  form  YYJJJHHMM. 

NanoS(2)  is  an  lnteger*4  array  that  indicates  the  quadword  time  in  hundreds  of 
nanoseconds  or  tenths  of  microseconds. 

Time  is  a  Character *23  that  indicates  the  time  in  VAX  Tune  String  Format  as  given 
by  the  runtime  library  routine  LIB$Date_Time  or  the  DCL  command  Show  Time. 

Description: 

CLK  Gettim  is  a  function  used  to  convert  from  one  time  format  to  another,  adding  a  time 
offset  if  requested.  It  is  particularly  useful  for  converting  between  Julian  time  and  VAX 
String  Time  for  use  in  data  base  requests  or  for  converting  local  time  to  GMT  (in 
conjunction  with  CLK_Offset).  The  use  of  this  function  requires  the  include  file 
AIMS_Includes:CLKDef.For. 

Example  Code  Stub: 

Integer*4  Time_OfFset(2)  /0,0/,  Iret,  CLK_Gettim 
Record  /CLK_Structure/  Clock 


Clock.Time  =  '06-OCT-1956  00:29:00.00' 

Iret  =  CLKGettim(CLK__ASCII, Clock, Off  set) 

Clock  Structure  Returns: 

Clock.  Year  =  1956 

Clock. Month  =  10 

Clock.Day  =  6 

Clock.Hour  =  0 

Clock.Minute  =  29 

Clock.  Second  »  0 

Clock. Hundredths  =  0 

Clock.  Julian  =  562810029 

Clock.  DayOfWeek  =  6 

Clock.Nanos(l)  =  '4DC4EE00X 

Clock.Nanos(2)  =  '0O6DBE0FX 

Clock.Time  =  06-OCT-1956  00:29:00.00' 

Condition  Values  Returned: 

CLK _ Ok  indicates  successful  completion. 

CLK _ BadArgs  indicates  that  one  of  the  input  arguments  is  invalid. 

CLK _ BadFunct  indicates  that  an  illegal  clock  function  was  requested. 
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CLK  OFFSET 


CLK_Offset  is  an  IntegerM  function  that  converts  a  Modified  Vax  Tune  String  to  a  two's 
complement  q midword  (1*8)  for  time  offset  calculations. 


Formal  Iret  -  <XK_Offset(Time_Off*et,  LogicaLTaWe,  Logical _Name, 

TimeJString) 


Returns  Status  return  values  are  listed  under  Condition  Values  Returned. 


Arguments: 

TimeOffset  is  a  two  element  IntegerM  array  into  which  the  quad  word  time  offset  is 
written  in  hundreds  of  nanoseconds. 

Logical_Tab!e  is  a  Character^  that  indicates  which  logical  table  to  refer  to  for  the 
logical  name  of  the  clock  offset.  For  example,  'LNM$SYSTEM_TABLE*  or  ’*'  when  the 
Time_String  offset  is  given. 

Logical  Name  is  a  Character*n  holding  the  time  offset  in  Modified  Vax 
Time  String  format.  Examples  are  '(XK_GMT  JMFFERENCE'  for  the  offset 
from  local  time  and  when  the  Time_String  offset  is  given. 

Time_String  is  a  Character*24  containing  a  Modified  Vax  Time  String 
indicating  the  desired  time  offset.  Since  the  offset  represents  a  departure  from  VAX 
"O'  time  they  have  a  format  such  as  '+17-NOV-1858  04:00:00.00’  for  an  offset 
of  positive  4  hours.  If  the  logical  name  approach  is  used  then  Time_String  is 
passed  as  a 

Description: 

CLK_Offset  is  used  primarily  in  conjunction  with  another  Dock  function  (CLK_Gettim)  in 
order  id  facilitate  the  computation  of  a  single  time  or  series  of  times  offset  from  some 
known  time.  An  example  of  such  a  use  would  be  for  requesting  data  observations  for  a 
series  of  times  or  determining  GMT  time  from  local  time.  If  Time  String  *  then  the 
logical  table  specified  in  Logicaf_TabIe  is  searched  for  the  Modified  Vax  Time  (and  then 
returned  to  Time_String).  Time  Offset  is  returned  with  the  number  of  hundreds  of 
nanoseconds  representing  TimeJString. 

Example  Code  Stub: 

IntegerM  Time_Offset(2),  Iret,  CLK_Offset 
Character*24  Time_String  /’*'/ 


Iret  =  CLK_Offset(Time_Offset,'LNM$SYSTEM_TABLE', 

'CLK_GMT_DIFFERENCE',Time_String) 


Returns: 

bet«CLK_Ok 

Tiroe_String  «  +17-NOV-1958  Q5.-(»OO.OCr 
TimejOffsetll) «  0E8D6080OX 
Time_Offset(2)  *  0000002TX 
Condition  Values  Returned: 

CLK_Offiiet  returns  either  CLK _ Ok  or  the  error  codes  from  JTmlnm  or  SBintfm. 
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CLK  JD  A  Y  OFWEEK 


CLKJDayOfWeek  is  an  Inieger*4  function  that  given  a  day,  will  determine  dock  dan  for  a 
given  day  of  the  week  around  that  day. 


Format  Iret  *  CLK_DayOfWeek(Clock,  RefJDay,  JulianJStriag) 


Return*  Status  return  values  are  listed  under  Condition  Values  Returned. 


Arguments: 

Clock  is  a  structure  defined  in  AlMS^bcludes^lKDefAv  with  the  structure  name 
CLK.Structure.  When  passed.  Clock  must  contain  at  a  minimum  the  ‘Nanos’  element  of 
the  day  of  interest  Upon  successful  completion  all  dements  are  defined  concerning  the 
day  of  the  week  around  the  original  date  for  which  clock  data  was  requested. 

These  dements  are  described  below: 

Year  is  an  Integer*2  that  indicates  die  year  in  the  form  19XX. 

Month  is  an  Integer*2  that  indicates  the  month  in  numeric  form  from  1  to  12. 

Day  is  an  Integer*2  that  indicates  the  day  in  numeric  form  from  1  to  31. 

Hour  in  an  Integer*2  that  indicates  the  hour  in  the  range  0  to  23. 

Minute  is  an  Integer*2  that  indicates  the  minute. 

Second  is  an  Integer*2  that  indicates  the  second. 

Hundredths  is  an  Integer*2  that  indicates  the  hundredth  of  second. 

DayOfWeck  is  an  Integer*4  that  indicates  the  day  of  the  week  where  Monday  is 
day  1  and  Sunday  is  day  7. 

Julian  is  an  Integer*4  that  indicates  the  Julian  date  in  the  form  YYJJJHHMM. 

NanoS(2)  is  an  Jnteger*4  array  that  indicates  the  quadwond  time  in  hundreds  of 
nanoseconds  or  tenths  of  microseconds. 

Time  is  a  Character*23  that  indicates  the  time  in  VAX  Time  String  Format  as 
given  by  tht  runtime  library  routine  LIB$Date_Time  or  the  DCL  command  Show 
Time. 

Ref_Day  is  an  Integer*4  that  defines  the  day  of  the  week  about  which  clock  data  is 
requested.  It  is  defined  by  parameters  listed  in  AIMS_Includes:CLKDef.For. 

CLK _ Monday,  CLK _ Tuesday,  CLK _ Wednesday,  CLK _ Th  ursday , 

CLK _ Friday,  CLK _ Saturday,  and  CLK _ Sunday  indicate  interest  in  those  days 

of  the  week. 
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CLK_MJLast  when  logically  Wed  with  one  of  the  above  day  parameters  indicates 
interest  in  that  day  of  the  week  for  the  preceding  week. 

CLKJM_Next  when  logically  Wed  with  one  of  the  above  day  parameters  indicates 
interest  in  that  day  of  the  week  for  th t  following  week. 

Julian jString  is  a  Character^  which  upon  return  from  the  routine  contains  the  Julian 
date  (in’ the  format  'YYJJJ')  for  the  day  of  reference. 

Description: 

CLKJDayOfWeek  is  a  function  used  to  determine,  given  any  calendar  day,  the  date  of 
occurrence  of  some  day  of  the  week  either  in  the  week  before,  the  week  of,  or  the  week 
following  that  day.  CLK_DayOfW eek  is  used  primarily  in  conjunction  with  the  ADB 
functions  in  order  to  facilitate  the  computation  of  the  conventional  meteorological  data  file 
generation  dates.  QLK_DayOfWeek  requires  use  of  the  include  file 
AIMS_Includes:CLKDef.For. 

Example  Code  Stub; 

IntegerM  Time_Offset(2),  Iret,  CLK_Gettim,  CLKJDayOfWeek 
Character4^  Julian_String 


Gock.Time  =  02-OCT-1956  00:29:00.00’ 

Iret  =  CLK_Gettim(CLK_ASCn,aock, Offset) 

Iret  =  CLKjDay__OfjWeek(Clock,CLK _ Saturday  JulianJitring) 

Clock  Structure  Returns: 

Qock.Year  =  1956 

Gock. Month  =  10 

Clock.Day  =  6 

Clock. Hour  =  0 

Clock.Minute  =  29 

Clock.Second  =  0 

Clock.Hundredths  =  0 

Gock  Julian  =  562810029 

Clock.  DayOfWeek  =  6 

Clock.Nanos(l)  =  4DC4EE00’X 

Clock.Nanos(2)  =  006DBE0FX 

Gock.Time  =  '06-OCT-1956  00:29:00.00’ 

Julian_String  =  ’56281’ 

Condition  Values  Returned: 

CLKJDayOfWeek  returns  either  CLK _ Ok  or  the  error  codes  from  STmlnm, 

SBintim,  or  CLK_Gettim. 


Appendix  E:  General  Purpose  AIMS  Applications 

Plot_Wx 

This  application  generates  a  plot  of  conventional  data  and  associated  geopolitical 
map  on  the  graphics  display  based  on  an  input  day,  time,  geographic  location  and 
meteorological  parameters).  The  location  defines  an  area  that  can  be  centered  on  a  station, 
state,  sectional  area  or  latitude-longitude  box.  Options  allow  the  user  to  control  both  the 
color  and  the  display  projection.  All  data  sources  are  supported;  valid  data  types  arc 
source-dependent  An  example  of  output  produced  by  Plot_Wx  is  shown  in  Figure  E-l. 

ContourWx 

This  application  generates  a  contoured  analysis  of  conventional  data  and  associated 
geopolitical  map  on  the  graphics  display  based  on  an  input  day,  time,  geographic  location 
and  meteorological  parameters).  The  location  defines  an  area  with  the  same  options  as 
Plot_Wx.  Other  options  allow  die  user  to  control  color,  contour  increment  and  mid-level 
contour,  display  projection  and  aspects  of  the  spatial  objective  analysis.  All  data  sources 
are  supported;  valid  data  types  are  source  dependent  An  example  of  output  produced  by 
Contour_Wx  is  shown  in  Figure  E-2. 

SkewT 

Skew_T  plots  a  skew-T/log-P  thermodynamic  diagram  on  the  graphics  display 
based  on  an  input  day,  time  and  station.  The  plot  includes  wind  flags  drawn  at  mandatory 
pressure  levels  and  calculations  of  the  K  Index,  Lifted  Index  and  Lifted  Condensation 
Level.  Options  allow  the  user  to  select  an  alternate  range  for  the  axes,  plot  the 
thermodynamic  path  of  a  hypothetical  air  parcel,  plot  an  additional  sounding  as  an  overlay 
and  include  moist  adiabats  as  part  of  the  diagram.  Figure  E-3  is  an  example  of  output 
produced  by  Skew_T. 

XSection 

This  application  generates  a  cross-sectional  analysis  on  the  graphics  display  from  a 
collection  of  upper  air  soundings  bounded  by  a  latitude-longitude  box  defined  from  user- 
specified  end  points.  The  end  points  define  a  2 -dimensional  analysis  plane  that  is  generated 
using  the  raw  sounding  data,  interpolated  to  the  analysis  plane  using  the  empirical 
technique  of  Bames  (1964).  The  display  consists  of  contoured  fields  of  temperature,  wind 
speed,  potential  temperature  and  specific  humidity.  The  visibility  of  each  field  can  be 
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independently  controlled  by  the  user.  An  example  of  output  produced  by  XSectkw  is 
shown  in  Figure  E-4. 

I 

MDR 

This  application  generates  a  radar  depiction  on  die  graphics  display  using  Manually 
Digitized  Radar  (MDR)  data  based  on  an  input  day,  time  and  geographic  location.  Values 
of  the  Digital  Video  Integrator  Processor  (DVIP)  Scale  (related  to  rain  rate)  are  plotted  and  1 

color  coded  to  visually  depict  die  scale.  The  location  defines  an  area  with  the  same  options 
as  Plot_Wx.  Cloud  top  heights  and  cell  motion  are  also  plotted  if  available.  Figure  E-5  is 
an  example  of  output  produced  by  MDR. 

Bolt 

Bolt  produces  a  plot  of  lightning  strike  locations  and  a  background  geopolitical  map 
based  on  an  input  day,  time  and  geographic  location.  The  location  defines  an  area  with  the 
same  options  as  Plot_Wx.  Options  also  allow  the  user  to  control  both  the  color  and  die 
display  projection.  The  user  can  also  generate  a  time  series  of  lightning  strikes  based  on 
input  begin-  and  end-times  and  a  time  interval.  The  resulting  output  display  is  color  coded 
according  to  time  interval.  An  example  of  output  produced  by  Bolt  is  shown  in  Figure  E-6. 

ListADB 

This  application  generates  a  text  listing  of  conventional  meteorological  data.  For  a 
geographic-based  listing,  the  user  specifies  a  single  day,  time  and  location.  Location  can 
be  a  single  station,  multiple  stations  or  an  area  centered  on  a  station,  state,  country, 
sectional  area  or  latitude-longitude  box.  For  a  time  series  listing,  die  user  specifies  a  start 
and  stop  date/time  and  a  time  increment  for  a  single  station.  The  user  has  control  over  the 
output  format  of  the  listing  and  can  direct  the  output  to  either  the  terminal  or  a  disk  file.  All 
data  sources  are  supported;  valid  data  types  are  source  dependent.  Table  E-l  is  a  sample 
listing  of  output  produced  by  List_ADB. 

ObservationWx 

This  application  generates  a  text  listing  of  Service  A  data  to  the  terminal  screen  or  to 
a  disk  file.  For  a  geographic  based  listing,  the  user  specifies  a  single  day,  time  and 
location.  Location  can  be  a  single  station,  multiple  stations  or  an  area  centered  on  a  state  or 
province.  For  a  time  series  based  listing,  the  user  specifies  a  start  and  stop  date  and  time 
increment  for  a  single  station.  Table  E-2  is  an  example  listing  produced  by 
Observation_Wx. 
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SID 

SID  generates  a  text  listing  of  station  data  based  on  an  input  geographic  location. 
Location  can  be  a  single  station,  multiple  stations  or  an  area  centered  on  a  station,  state, 
province,  country  or  latitude-longitude  box.  Station  data  include  station  identifier,  station 
number,  latitude,  longitude,  elevation,  descriptive  location,  state  or  province,  country  of 
origin  and  reporting  class  (e.g.,  synoptic,  guidance).  Options  allow  the  user  to  list  stations 
of  a  particular  reporting  class  and  to  list  only  those  stations  that  report  on  a  regular  basis.  A 
example  of  output  produced  by  SID  is  shown  in  Table  E-3. 

Fous 

Fous  generates  a  text  listing  of  LFM-based  guidance,  MOS  (Model  Output 
Statistics)  or  trajectory  forecasts  based  on  an  input  day,  time  and  station.  An  option  allows 
the  user  to  direct  output  to  a  disk  file.  Table  E-4  is  an  example  of  output  generated  by  this 
application. 

Foue 

Foue  generates  a  text  listing  of  NGM-based  guidance  based  on  an  input  day,  time 
and  station.  An  option  allows  the  user  to  direct  output  to  a  disk  file.  Table  E-5  is  an 
example  of  output  generated  by  Foue. 

UpperAir 

This  application  generates  a  text  listing  of  an  upper-air  report  based  on  an  input  day, 
time  and  station.  Data  include  temperature,  dewpoint  temperature  and  winds  at  mandatary 
pressure  levels;  temperature  and  dewpoint  temperature  at  significant  pressure  levels;  and 
winds  at  significant  height  levels.  An  example  of  output  produced  by  Upper_Air  is  shown 
in  Table  E-6. 
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Figure  E-2.  Contour  Analysis  of  Dewpoint  Temperature  Using  Service  A  Reports  for  an  Area 
Centered  on  New  York  at  21Z  on  August  4, 1992. 
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ALB  ALBANY  COUNTY  ARPT 

21-JUL-1898  18:00 
LCL:  897.3 

L1NDBX:  0.8 

K  INDEX:  38  4 


Figure  E-3.  Skew-T/Log-P  Diagram  Generated  from  die  Upper  Air  Report  for  Albany,  NY 
at  12Z  on  July  21 , 1992. 


Cross  Sectional  Analysis 


1  -  tsotachs (knots) 


2  -  Isotherms  ( C) 


-  Isentrops  f'C) 


4  -  Isohumes  (g/  k«) 


5  -  Exit 


Figure  E-4.  Cross  Sectional  Analysis  of  Temperature  and  Mixing  Ratio  for  a  Line 
Between  International  Falls,  MN  and  Albany,  NY  at  OZ  on  July  21, 1992. 


77 


--a  ■ , 


Figure  E-5.  Plot  of  MDR  Digital  Video  Integrator  Processor  (DVTP)  Intensity  Values 
for  the  U.S.  at  19Z  on  July  2,  1992. 
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Figure  E-6.  Plot  of  Lightning  Strikes  for  a  One-Hour  Period  Beginning  at  19Z  on  June  27, 
1992  for  an  Area  Centered  on  Vermont  Strike®  are  Color  Coded  by  15  Minut'  Time  Intervals. 
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Table  E-l.  Listing  of  Synoptic  Observations  for  the  United 
Kingdom  at  18Z  on  October  7,  1992. 
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Table  E-2.  Listing  of  Service  A  Observations  for  Montana  at  18Z 
on  October  6,  1992. 
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LTNhflnld«aot 
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Table  2-4 .  Listings  of  LfM  Guidance,  HOS,  and  Trajectory  forecasts  Valid 
122  for  Boston,  MA  on  August  10,  1992. 
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133 

180 

-605 

900 

142 

125 

155 

-681 

720 

60 

20 

150 

-645 

580 

-51 

-65 

115 

-763 

550 

-53 

-90 

520 

-81 

-301 

510 

-101 

-121 

500 

-107 

-247 

470 

-131 

-151 

430 

-179 

-221 

420 

-177 

-387 

390 

-211 

-451 

380 

-209 

-449 

270 

-401 

-601 

220 

-529 

E-6.  Upper  Air  Report  for  Sao  Paulo,  Brasil  at  122 
on  October  7,  1992. 


